КНИГА
31.01.02

Предыдущая часть

Консалтинг при автоматизации предприятий:
подходы, методы, средства

ЧАСТЬ 3

ЭТАПЫ РАЗРАБОТКИ КОНСАЛТИНГОВЫХ ПРОЕКТОВ

В третьей части книги рассматривается, как исследованные в главах 1-10 методы и средства структурного системного анализа могут быть использованы на ранних этапах разработки систем, т.е. будет намечена методология разработки консалтинговых проектов - общий подход к консалтингу, основанный на структурном анализе и проектировании.

В главе 11 обсуждаются основные этапы методологии и подробно описываются задачи и виды работ, выполняемых консультантом на этапе обследования предприятия.

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

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

ГЛАВА 11

ПРОВЕДЕНИЕ ОБСЛЕДОВАНИЯ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ

11.1. Цели и основные этапы консалтинга

Основными целями разработки консалтинговых проектов являются:

Структура подхода к разработке консалтинговых проектов приведена на рис. 11.1.

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

Рис. 11.1. Структура подхода

Первым шагом собственно разработки является предварительное изучение задачи. Предварительное изучение должно ответить на ряд вопросов:

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

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

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

В рамках этапа 2 (проведение обследования деятельности предприятия) осуществляется:

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

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

На этапе 3 (построение моделей деятельности предприятия) осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов:

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

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

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

Отметим, что для построения каждой из требуемых моделей необходима интенсивная работа 6-7 квалифицированных системных аналитиков в течении 2-4 месяцев.

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

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

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

Продолжение