Этапы индивидуального внедрения ИС

Внедрение информационной системы должно осуществляться в тесном сотрудничестве поставщика и собственных специалистов предприятия, внедряющих данную систему. Процесс внедрения следует начать с назначения менеджера проекта и создания команды высококвалифицированных специалистов, подготовку которых и сертификацию желательно предварительно провести у поставщиков системы. При этом приоритет во внедрении следует отдавать команде заказчика, а команде поставщика оставить роль консультационной и технической поддержки. В целом успех ИТ-проекта напрямую зависит от квалификации специалистов, внедряющих систему Какой бы ни был выбран вариант — покупная ИС или заказная разработка, этапы индивидуального внедрения примерно одинаковы и совпадают с каскадной моделью жизненного цикла системы в соответствии с ГОСТ 34.601−90 «Автоматизированные системы. Стадии создания» (рис. 7.1).

Рис. 7.1. Каскадная модель жизненного цикла ИС.

На этапе формирования требований проводится обследование предприятия, на котором будет внедряться ИС. Результаты обследования удобнее представить в виде организационной диаграммы, определяющей структуру гипотетической гостиницы (рис. 7.2), и диаграмм плавательных дорожек (Swim Lane), представляющих в графической форме основные сценарии управленческой деятельности предприятия. На рис. 7.3 представлена диаграмма плавательной дорожки для сценария «Регистрация и размещение клиента». Для построения подобных графических диаграмм удобно воспользоваться пакетом BPwin. Следует иметь в виду, что приводимые в данном параграфе диаграммы имеют чрезвычайно упрощенный вид. На практике для описания процессов управления предприятием требуются десятки подобных диаграмм, а их разработка и согласование занимает не одну неделю и даже не один месяц.

Рис. 7.2. Организационная структура предприятия.

Данный комплект диаграмм может использоваться в качестве бизнес-модели «AS IS» («Как есть»). Эта модель позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации производства. Детализация процессов позволяет выявить недостатки организации даже там, где функциональность кажется очевидной. Признаком малоэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияние ее результат) и входу (объекты или информация используются нерационально) и т. д.

Найденные в модели «AS IS» недостатки должны быть исправлены при создании модели «ТО BE» («как должно быть») — модели новой организации процесса управления предприятием.

Рис. 7.3. Диаграмма Swim Lane для сценария «Регистрация и размещение клиента».

Результирующим документом этапа формирования требований является технико-экономическое обоснование (ТЭО) [ГОСТ 24.202−80, РД 50−34.698−90]. Документ ТЭО ИС должен состоять из следующих разделов:

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

На этапе разработки концепции ИС выполняются работы по наведению элементарного порядка в управленческих процессах предприятия и реструктуризации (реинжиниринга) бизнес-процессов на основании модели «AS IS» [Коваленко В.В.]. На этом этапе специалисты по внедрению должны выполнить тщательное обследование предметной области с позиций системного подхода:

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

Результаты обследования используются для разработки функциональной модели «ТО BE» в виде иерархической функциональной модели на основе методологий IDEFO, IDEF3, DFD [Маклаков]. Эта модель будет содержать весь набор функций, которые планируется автоматизировать с помощью ИС. Оптимизация бизнес-процессов в модели «ТО BE» выполняется на основе последовательного использования технологий ISD (Information Systems Design — планирование информационных систем) и BPR (Business Processes Redesign — реинжиниринг бизнес-процессов).

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

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

ности предприятия (рис. 7.5). При этом все дуги с контекстной диа граммы автоматически переносятся на эту диаграмму.

Рис. 7.4. Контекстная диаграмма модели гостиницы.

Рис. 7.5. Диаграмма первого уровня декомпозиции модели гостиницы.

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

Рис. 7.6. Дерево узлов функциональной модели гостиницы.

Следует отметить, что при построении модели «ТО ВЕ» необходимо максимально удовлетворять требованиям процессного подхода к управлению, то есть правильно определять состав функций каждого бизнес-процесса на нижних уровнях иерархии. Выходом каждого бизнес-процесса должен воспользоваться хотя бы один клиент, необходимо максимально сократить количество подразделений, поскольку большинство проблем возникает на границах между подразделениями организации. Для этого надо либо заранее описать действия на всех этапах бизнес-процесса, либо изменить структуру подразделений, либо изменить поток работ.

Полученная на предыдущем этапе функциональная модель позволяет определить функциональный состав, потоки информации, содержание входной и выходной информации, структуру пользовательского интерфейса требуемой системы. Этой информации достаточно для разработки технического задания (ТЗ) на ИС [ГОСТ 34.602−89], которое является основным юридическим документом во взаимоотношениях между поставщиком и заказчиком.

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

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

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

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

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

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

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

Возможно также осуществление на автоматизируемом предприятии пилотного внедрения ИС или деловой игры для специалистов предприятия. Для этого на предприятии развертывается конфигурация системы, которая функционально соответствует утвержденной версии модели бизнес-процессов «ТО BE», но с небольшим количеством рабочих мест только для ключевых пользователей. Организационная структура моделируемого предприятия может быть в разумных пределах также упрощена.

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

Эган ввода в действие начинается с проведения опытной эксплуатации системы после устранения поставщиком обнаруженных при деловой игре недостатков [ГОСТ 34.603−91]. Это стадия реальной эксплуатации новой системы на ограниченном количестве рабочих мест. Все учетные операции в это время ведутся в «старой» системе, если она имеется. Для проведения опытной эксплуатации разрабатываются программа и методики испытаний, создается приказом руководителя предприятия комиссия по проведению испытаний [РД 50−34.698−90]. По результатам опытной эксплуатации создается акт, в котором отмечаются все обнаруженные ошибки или несоответствия техническому заданию и бизнес-модели.

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

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

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

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