Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Inf_comp_sys

.pdf
Скачиваний:
10
Добавлен:
21.03.2016
Размер:
3.33 Mб
Скачать

Определение функциональных областей и процессов должно быть независимо от текущей организационной схемы предприятия, формально отражающей его функции и процессы. Организация может изменяться, но при этом осуществлять те же функции и процессы. Некоторые корпорации каждые два года подвергаются перестройке, которая проходит не безболезненно. Важно понять, что формальная организационная схема предприятия обычно не так уж хорошо представляет функции и процессы.

Процессам дают названия, ориентированные на действия, как, например, на рисунке 4. Они должны представлять основные виды деятельности и области принятия решений, не зависящие от подотчетной иерархии и конкретных обязанностей руководителя.

Процессам можно давать простые определения. Например, управление запасами можно определить как процесс планирования поступления на склад и контролирования выдачи со склада сырья, деталей и комплектующих изделий.

Каждый процесс может относится к работе одного или нескольких подразделений. Склад может быть один или несколько, но процесс идет.

Жизненный цикл той или иной продукции, службы или ресурса предприятия можно разбить на четыре стадии: планирование, приобретение,

изготовление и реализация. На рисунке 4 перечислены типы процессов, которые могут существовать на каждой из этих стадий. Это можно проделать с финансами, персоналом, сырьем, деталями, готовой продукцией, оборудованием, постройками, станками, арматурой и т.д. Такой подход помогает идентифицировать сами процессы.

71

Идентифицированные процессы можно разнести по исполнителям в

организации и оформить в виде таблицы, отражающей долю участия и ответственности каждого участника того или иного процесса (рис. 5). Такую таблицу можно использовать для определения тех лиц, которых необходимо опросить об этих процессах, что поможет исключить возможность пропуска каких-либо важных процессов.

В списке процессов не должно быть дублирования. Не следует искусственно объединять процессы для исключения их числа.

8.3Действия

В каждом процессе на предприятии выполняется ряд действий. Например на рисунке 6 одним из процессов является закупочная деятельность. В этом процессе надо выполнить следующие действия:

Подготовить требования на закупку.

Выбрать поставщика.

Подготовить закупочные заказы.

Довести до конца поставки элементов закупочных заказов.

Отработать исключения.

Подготовить информацию для счетов кредиторов.

Записать данные о работе поставщиков.

Проанализировать работу поставщиков.

72

В каждом процессе выполняется обычно от 5 до 30 действий. Разбиение на процессы и действия носит несколько искусственный характер и чисто терминологически определяет границы разукрупнения списка функциональных областей на составляющие их функции, выполняемые отдельными подразделениями, службами и конкретными исполнителями. Функцию самого низкого уровня можно назвать действием и его описание должно начинаться с глагола, обозначающего выполняемую операцию.

При отсутствии схемы действий невозможно достаточно полно оценить наличие аналогичных действий, выполняемых различными подразделениями. Дублирование действий порождает и дублирование создаваемых различными подразделениями форм и отчетов, повышающих стоимость программирования и ведения. Процедуры обработки данных в компьютеризированной корпорации должны отличаться от процедур в корпорации, где бумажная отчетность обрабатывается вручную. Большинство таких процедур должно выполняются оперативно, с контролем избыточности данных и минимальном разнообразии прикладных программ. Возможность получения любой информации на экране терминала или компьютера исключает тиражирование большого числа бумажных копий документа, а иногда и полностью исключает его бумажных вариант. Дублирование действий обнаруживается с помощью схем отображения данных на действия.

Таким образом, централизованное планирование переходит из сферы ЭОД в сферу управления предприятием и заставляет задуматься о его реорганизации.

8.4Характеристики модели предприятия

Полнота: модель должна представлять полный список функциональных служб, процессов, функций и действий, составляющий данное предприятие.

Адекватность: процессы, функции и действия должны представляться правильными и естественными как для руководителей данного уровня.

Постоянство: модель должна оставаться обоснованной и действенной до тех пор, пока сохраняется назначение предприятия, независимо от реорганизаций и того, где хранятся данные - в файлах, базах данных или на бумаге.

8.5Планирование с разной степенью разрешения

Централизованное планирование с более низкой степенью разрешения

"работает" на уровне организационных процессов и предметных баз данных,

планирование же с более высокой степенью разрешения - на уровне

организационных действий и объектов данных.

Можно сначала разработать план с меньшим разрешением, а затем уже, вдаваясь в подробности, разработать план с более высокой степенью разрешения.

73

8.6Группировка функций

Иерархическое разбиение функций (рис. 6) следует остановить при получении действия, которое реализуется как физическая процедура, выполняемая вручную, с помощью компьютера или диалога с терминала, который заранее не определишь.

74

75

Действия соотносят с объектами на схеме объектов. Для устранения избыточности модель с включением действий и объектов можно реорганизовать: избыточные объекты объединить, а избыточные действия слить; затем можно сгруппировать логические действия в функционально связанные соединения, которые в основном образуют автономные группы. Такую логическую группировку функций можно назвать логической функциональной областью. Логические функциональные области образуют основу информационных систем, пользующихся одними и теми же данными.

Логические функциональные области, полученные таким образом часто отличаются от коммерческих (фактических) функциональных областей (рис. 6).

Коммерческие функциональные области сложились в результате исторический, практически (на тот момент) целесообразных, политических и организационных соображений, имевших место в прошлом, и часто они представляют не самую лучшую базу для информационных систем.

8.7Назначение и цели предприятия

При централизованном планировании данных возможно изучение цели и назначения предприятия с последующей формализацией стоящих перед ним задач.

Задачи должны быть измеримыми, и нужны схемы отчетов, гарантирующие выполнение этих измерений соответствующими исполнителями. Задачи высшего уровня следует разбивать на задачи подразделений. Чтобы гарантировать их выполнение, задачи нужно четко определить и перевести на человеческий язык в виде мотивированных инструкций.

8.8Критические факторы успеха

Критические факторы успеха это те факторы, которые руководитель предприятия считает наиболее жизненно важными для успеха своей организации.

Формулировки цели и назначения предприятия часто отличается от критических факторов успеха.

Часто выбор критических факторов успеха, сделанный главным руководящим лицом, не соответствует тому, который сделал бы проектировщик информационной системы.

Большинство данных, необходимых для анализа руководством критических факторов успеха, не возможно получить как побочный продукт обычной обработки данных. Их надо собирать специально из других источников (например: официальные и не официальные беседы руководителей со служащими).

Для измерения и контроля достижения целей, анализа задач руководством и анализа критических факторов успеха как часть стратегического планирования данных должны составляться отчеты. Отчеты должны включаться в качестве действий в такую подробную схему действий предприятия, как на рис.6.

76

Глава 9. Организация централизованного планирования

Организация централизованного планирования подразумевает ряд шагов и мероприятий, позволяющих объединить усилия и скоординировать совместные действия разработчиков и пользователей по созданию корпоративной информационной системы.

9.1Организация анализа

Для проведения анализа стратегического планирования данных необходимо создание рабочей группы, которая представляет себе данную методологию и обладает опытом ее применения.

Если в организации нет людей с опытом применения стратегического планирования данных, то необходимо пригласить консультанта со стороны, который должен предложить формальную, опробованную методику, желательно уже реализованную в программных средствах автоматизации планирования и проектирования данных.

Не следует целиком передавать планирование консультантам.

Руководителем группы планирования должен быть служащий корпорации.

Во главе централизованного планирования должен стоять один человек -

планировщик информационных ресурсов. Как и в администрировании данных,

за общий проект должен отвечать один компетентный, обладающий властью человек, имеющий в своем распоряжении нужные средства и методы.

Высшее руководство должно прислушиваться к мнению планировщика информационных ресурсов и ставить подпись на его планах.

Планирование должно осуществляться небольшой группой-ядром с твердым руководством (рис. 7).

Этой группе потребуется большая помощь со стороны пользователей в корпорации. Нужно выбрать ответственных от подразделений пользователей. Некоторыми из них должны быть руководители отделов. Форма их участия в работе при разных методологиях различна. Иногда руководителей отделов пользователей просто опрашивают, иногда пользователей обучают, как выдавать информацию о своей деятельности. Таких участников процесса планирования будем называть пользователями-аналитиками.

Когда к работе привлекаются руководители подразделений или конечные пользователи, необходимо умение представлять им концепции на нетехническом языке.

На рисунке 8 показана связь между планированием сверху вниз,

осуществляемым планировщиком информационных ресурсов (или рабочей группой-ядром), и детальным проектированием снизу вверх, осуществляемым администратором (администраторами) данных. Планировщику сверху вниз открыта перспектива всей корпорации, и он решает, какие базы данных или другие ресурсы данных нужны корпорации. Администратор данных проводит анализ и синтез данных для каждой создаваемой базы данных. При этом планировщику информационных ресурсов нужна помощь от каждой функциональной области, но не на слишком подробном уровне, в то время как

77

администратору данных необходимо, чтобы комитеты пользователей подробно рассматривали каждую предметную базу данных по очереди с целью сделать их как можно стабильнее.

78

79

Как планировщику информационных ресурсов, так и администратору данных требуются вычислительные средства. При выполнении такой работы вручную проектировщики ищут возможности сокращения детальной проработки и сопротивляются внесению изменений в составляемые схемы из-за большой трудоемкости оформления. Вычислительные средства планирования сверху вниз должны быть совместимы со средствами проектирования снизу вверх, дополнять и проверять друг друга.

9.2Временная шкала

Планирование сверху вниз должно завершиться за шесть месяцев. При отсутствии твердой методологии или твердого руководства планирование может длится гораздо дольше и полностью дискредитировать себя. Из-за непрерывного давления, связанного с разработками новых приложений, планирование сверху вниз следует осуществлять быстро и решительно.

Если через шесть месяцев оказывается, что работы завершены на 90%, то остальные 10% приходятся на неопределенность в отношении этапа, на котором следует остановиться. Важно, чтобы полученные результаты были используемыми после шести месяцев работы, даже если какие-либо тонкости остаются неясными.

Если детальное моделирование данных и процесс проектирования откладываются до момента завершения плана сверху вниз и само моделирование данных занимает длительное время, запаздывание в целом может быть на столько велико, что повредит задачам быстрой разработки приложений.

Иногда стараются решить слишком много вопросов при планировании сверху вниз. Это может привести к тому, что составление общего плана не завершится в разумных пределах времени. Группе планирования сверху вниз не следует заниматься нормализацией записей или спорить об определениях атрибутов. Когда это происходит, процесс застревает в обсуждении подробностей.

9.3Разработка модели предприятия

Разработка модели предприятия может проходить в три этапа:

разработка модели, показывающей функциональные области предприятия;

расширение модели с включением процессов;

расширение модели с включением действий (используется не всегда).

Функциональную модель можно представить в виде блок-схемы, каждый блок которой соответствует одной из главных функциональных областей предприятия. Стрелки между блоками могут показывать подчиненность или жизненный цикл продуктов, служб и ресурсов. У разных типов организаций различные пути представления своей функциональной модели.

80

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]