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

 

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

Этап 2. Проведение обследования деятельности предприятия. Этот этап включает определение организационной и топологической структур предприятия, анализ распределения функций по подразделениям и сотрудникам, определение перечня применяемых на предприятии средств автоматизации, предварительное выявление требований, предъявляемых к будущей системе, определение перечня целевых задач (функций) предприятия. При проведении обследования целесообразно применять следующие методы: 1) анкетирование; 2) сбор документов; 3) интервьюирование.

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

Этап 3. Построение и анализ моделей деятельности предприятия. Под моделью понимают описание проектируемой технологии (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы. Наиболее удобным языком моделирования бизнес-процессов является IDEFO, предложенный более 20 лет назад Дугласом Россом. Ранее этот метод назывался SADT (Structured Analysis and Design Technique). Построение и анализ моделей деятельности предприятия относится к области бизнес-консалтинга. На данном этапе осуществляется обработка результатов обследования и построения функциональных, информационных и, по необходимости, событийных моделей следующих двух видов:

· модели «как есть» (as-is), которая представляет собой «снимок» положения дел на предприятии на момент обследования;

· модели «как должно быть» (to-be), интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков по совершенствованию деятельности предприятия.

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

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

При построении моделей обычно пользуются следующими рекомендациями:

· структурирование должно осуществляться в соответствии с видами деятельности и бизнес-процессами предприятия, а не в соответствии с его организационной и штатной структурой;

· первый (верхний) уровень модели должен отражать только контекст системы, т. е. взаимодействие предприятия с внешней средой;

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

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

· дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций (так, процесс «Прием на работу» содержит функции «Прием заявления», «Оформление приказа», «Регистрация» и т. д.). Обычно для моделирования бизнес-функции достаточно 2—3 уровней детализации, которая завершается описанием элементарного алгоритма с помощью миниспецификации;

· общее число уровней модели не должно превышать шесть или семь.

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

Результатом проведения анализа и оценки моделей являются предложения по:

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

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

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

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

· разработке проектов внутреннего и внешнего документооборота, проекта положения о документообороте, проекта альбома форм входных и выходных документов.

Этап 4. Разработка системного проекта (модели требований к будущей системе). Системный проект представляет собой концепцию построения новой технологии управления (условия функционирования будущей системы, распределение выполняемых функций между техникой и персоналом и между исполнителями, требования к программным, техническим, информационным и другим компонентам технологии и т. д.). Иногда системный проект называют моделью требований, так как этот проект в формализованном и достаточно наглядном виде представляет выявленные и согласованные требования заказчика. Следует отметить основное достоинство системного проекта. Для традиционной формы разработки проектов характерно то, что результат разработки заказчик мог впервые увидеть и оценить только на этапе ввода в эксплуатацию, когда большинство работ уже закончено. Известно, что исправление ошибок; допущенных на предыдущей стадии, обходится примерно в 10 раз дороже, чем ошибок, выявленных в текущей ситуации. Из этого следует, что наиболее критичными являются первые стадии проекта. Поэтому крайне важно иметь эффективные средства автоматизации ранних этапов реализации проекта.

Фактически на этапе разработки системного проекта дается ответ на вопрос: «Что должна делать будущая система?». Системный проект должен включать:

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

· комментарии к функциональной модели (спецификации процессов нижнего уровня в текстовом виде);

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

· концептуальную модель интегрированной базы данных (пакет диаграмм);

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

· предложения по организационной структуре для поддержки системы.

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

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

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

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

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

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

Данный этап включает разработку и создание технического проекта и обеспечивает разработку общих решений: 1) по всей технологии и ее частям; 2) функционально-алгоритмической структуре; 3) функциям персонала и организационной структуре; 4) структуре технических средств; 5) алгоритмам решений задач и применяемым языкам; 6) организации и ведению информационной базы; 7) системе классификации и кодирования; 8) программному обеспечению. На этом же этапе проводится разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

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

1) разработка рабочей документации, содержащей необходимые и достаточные сведения для обеспечения выполнения работ по вводу информационной технологии в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) АИТУ в соответствии с принятыми проектными решениями, ее оформление, согласование и утверждение;

2) разработка программ и программных средств АИТУ и разработка программной документации:

а) если принято решение о разработке оригинальной технологии специалистами предприятия, то программирование модулей, их тестирование и отладка, комплектация в АРМы специалистов и единую технологию;

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

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

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

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