Цели и основные этапы разработки консалтинговых проектов

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

упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;

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

рекомендации и предложения по применимости и внедрению существующих систем управления предприятиями, и прежде всего, систем классов MRP (manufacturing resource planning) и ERP (enterprise resource planning).

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

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

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

• В чем недостатки существующей ситуации?

• Какие улучшения возможны?

• На кого окажет влияние новая система?

Рис. 8 Этапы разработки консалтингового проекта.

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

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

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

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

• предварительное выявление требований, предъявляемых к будущей системе;

• определение оргштатной и топологической структур предприятия;

• определение перечня целевых задач (функций) предприятия;

• анализ распределения функций по подразделениям и сотрудникам;

• определение перечня применяемых на предприятии средств автоматизации.

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

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

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

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

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

На практике используются два метода описания бизнес-процессов: “ускоренный” и “полный”.

Основные шаги "ускоренного" метода:

определение внешнего окружения организации (внешних входов и выходов);

выделение основных и вспомогательных бизнес-процессов организации;

определение связей между бизнес-процессами;

выделение функций каждого бизнес-процесса;

определение подразделений – исполнителей функций;

описание реализации каждой функции;

определение исполнителей каждого шага реализации и составление матрицы ответственности бизнес-процесса.

"Ускоренный" метод обладает следующими недостатками:

1.Субъективность определения перечня процессов верхнего уровня и привязки к ним внешних входов/выходов;

2.Сложность и субъективность определения внутренних входов/выходов для основных и вспомогательных процессов;

3. Субъективность определения вспомогательных процессов;

4. Сложность и субъективность отнесения функций организации к тем или иным процессам;

5.При детальном описании границы процессов подвержены сильным изменениям;

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

7. При создании сети процессов часть функций подразделений оказывается не привязанной с определенному процессу.

Основные шаги "полного" метода:

определение внешнего окружения организации (внешних входов и выходов);

выделение структурных подразделений организации, их взаимосвязей и связей с окружением;

выделение функций, реализуемых каждым подразделением;

определение связей между функциями и выделение бизнес-процессов внутри подразделений;

выделение бизнес-процессов организации;

составление матриц ответственности подразделений и бизнес-процессов.

Второй метод требует большего времени, однако он позволяет получить более полную, объективную и корректную модель.

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

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

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

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

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

• составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними;

• анализ применимости существующих систем управления предприятиями классов MRP и ERP для решения требуемых задач и формирование рекомендаций по выбору системы;

• совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы;

• разработка требований к техническим средствам;

• разработка требований к программым средствам;

• разработка предложений по этапам и срокам автоматизации.

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

• уточнение логической модели (разработка подробной логики каждого процесса с использованием диаграмм потоков данных и спецификаций процессов);

• проектирование физической базы данных;

• построение иерархии функций модулей, подлежащих программированию;

• оценка затрат на реализацию.

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