План внедрения 1С
План внедрения: новое и забытое старое
Вступление
В конце 70-х годов в Америке появился новый (по тем временам) прогрессивный стандарт MRP. Его возникновение и массовое использование стало ответом на хлынувший в Штаты поток дешевых японских автомобилей и угрозу знаменитому американскому автомобилестроению. Внедрение новой концепции позволило значительно повысить эффективность производства и уменьшить себестоимость выпускаемой продукции.
Практическая реализация стандарта невозможна без внедрения комплексной системы автоматизации. Один из разработчиков MRP Оливер Уайт предложил и стал широко применять подробный план внедрения программ комплексного управления предприятием (MRP-программ).
Этот план был проверен опытом тысяч компаний в течение 20 с лишним лет. Он широко использовался для внедрения MRPII, ERP и других технологий, так что сам стал фактически стандартом. В дальнейшем мы будем называть его планом Уайта.
Рассмотрим план Уайта подробнее, сравним его с российским ГОСТом и планами внедрения некоторых известных ИТ-компаний (Scala, Галактика, ЭпикРус и др.). Проанализируем приемы внедрения ПО, разработанного методом “экстремального программирования”.
План Уайта
Первые шесть этапов проекта составляют так называемый нулевой цикл. По их результатам принимается решение о внедрении. До недавнего времени нулевой цикл создавал много проблем. Заказчик не понимал, за что он должен платить, а ИТ-компании не могли или не хотели самостоятельно финансировать этот недешевый этап.
Сегодня клиенты все чаще признают необходимость оплаты нулевого цикла, независимо от его результатов. Скорее всего, это связано с накопленным опытом неудачных внедрений у себя и “соседей”.
Нулевой цикл включает:
предварительное обследование и оценку состояния (предпроектное обследование);
предварительную переподготовку;
техническое задание;
технико-экономическое обоснование;
организацию проекта;
выработку целей.
Рассмотрим каждый этап подробнее.
Предпроектное обследование
В настоящее время предварительное обследование проводят почти все ИТ-компании (за исключением очень маленьких и неопытных). Группа консультантов исследует предприятие-клиент, собирает детальную информацию о его структуре и организации деятельности. Полученные данные систематизируются и анализируются.
С помощью специализированных средств (например BPWin) строится диаграмма бизнес-процессов (обычно – в нотации DFD), каждый из которых характеризуется объемным блоком информации:
№ и наименование процесса;
№ и наименование процесса верхнего уровня;
№№ и наименования вложенных детальных процессов следующего уровня;
текстовое описание процесса;
перечень выходов процесса (документы, файлы, материальные ресурсы, являющие результатом выполнения процесса);
события, инициирующие процесс;
события, завершающие процесс;
перечень функций процесса;
перечень функций, контролирующих выполнение процесса;
перечень входящих документов;
перечень входящих материальных ресурсов;
перечень исходящих документов;
перечень исходящих материальных ресурсов;
перечень подразделений и должностей, участвующих в процессе;
типы используемых систем автоматизации.
На основе исследований строятся модели “as is” (как есть) и “to be” (как должно быть). Реорганизация представляет собой переход от одной модели к другой и позволяет навести элементарный порядок в организации процессов.
В наиболее полном случае результатом предпроектного обследования являются следующие документы:
схема бизнес-процессов “as is”;
схема бизнес-процессов “to be”;
бизнес-план реорганизации;
краткосрочный план действий.
Как правило, руководство фирмы-заказчика требует также определить приблизительную продолжительность и стоимость проекта.
Предварительная переподготовка
Цель – объяснить высшему руководству, что представляет собой процесс внедрения. Важно преодолеть различия в понимании процесса разными категориями сотрудников. Руководители должны придти к единому видению результатов и необходимых ресурсов.
К сожалению, значение этого этапа часто недооценивается консалтинговыми и ИТ-компаниями, что создает ряд сложнейших проблем.
Руководителю предприятия следует понимать, что процесс обследования почти наверняка будет воспринят персоналом “в штыки”. Во-первых, специалистам придется отвлекаться от работы, выполнение которой с них, тем не менее, будут требовать. Во-вторых, произойдет ломка межличностных отношений, которые подчас являются капиталом, результатом многолетних усилий сотрудников.
Пример из жизни:
– Петрович (зав. складом), отпусти “Кентавру” (покупатель). Я накладную попозже занесу, не хочу клиента заставлять ждать: берут много, платят налом.
– Нельзя.
– Да ты что? Всегда же так делали.
– А теперь шеф штрафует. Все – через компьютер.
– Во программеры… Дармоеды очкастые. Работать не дают. Разогнать бы!
Действовать предлагается не “по понятиям”, а по правилам. Для носителей российского менталитета это всегда тяжелое испытание (“Что я, сам не знаю, как лучше делать?”).
Описывая рабочие процессы, сотрудники подсознательно представляют не то, что есть на самом деле, а то, что им хотелось бы видеть. И очень обижаются, когда им указывают на это. Многие воспринимают “дознание” такого рода как “подсиживание” и поиск недостатков.
Есть ряд других проблем, но на них мы не будем сейчас останавливаться.
Вышесказанного достаточно, чтобы понять: сколько-нибудь глобальные вмешательства в деятельность компании требуют работы психолога, который поможет создать в коллективе атмосферу максимально благоприятного отношения к исследованиям. Нередко такие функции приходится брать на себя руководителю проекта. Полезно проводить исторические параллели, рассказывая, например, о движении луддитов и прозрачно намекая, что люди, стоящие на пути прогресса, будут неизбежно размолоты жерновами истории.
Техническое задание
Техническое задание – набор документов и спецификаций, определяющих требования к информационной системе и ее функциональности. В него входят:
требования к автоматизированным рабочим местам, их составу и структуре;
разработка требований к программным средствам;
разработка топологии, состава и структуры локальной вычислительной сети;
требования к секретности и защите информации.
Процессы системы делятся на:
ручные (регламентируются, но не автоматизируются);
пакетные (как правило, сбор статистических данных, получение отчетности за период, пересчеты глобальных регистров);
диалоговые (подавляющее большинство процессов в современных АСУП);
процессы реального времени.
Для автоматизированных процессов конкретизируются требования к виду и форме документов.
В составлении ТЗ принимают участие ИТ-специалисты, в частности разработчики, обладающие необходимым опытом и владеющие терминологией. Результат – подробный официальный документ, в котором отражены перечисленные выше требования или их допустимое подмножество. После составления технического задания можно реально оценить сроки и стоимость реализации проекта.
Формально составление технического задания – работа заказчика, однако в большинстве случаев этим занимается фирма, проводящая внедрение.
Технико-экономическое обоснование
Анализ “затраты-эффект” позволяет принимать обоснованные решения и подтверждает финансовую необходимость изменений.
Для систем MRP/ERP козырная карта ТЭО – управление запасами и логистика. В результате внедрения существенно уменьшаются запасы на складах, сокращается цикл производства, исчезает дефицит товаров и комплектующих и т. д. Все эти преимущества имеют строгое количественное выражение (стоимость аренды складских помещений, затраты на перевозки и др.). В результате расчет экономического эффекта становится делом техники и ТЭО выглядит вполне убедительно.
В то же время определение и количественная оценка некоторых статей расходов до сих пор вызывает трудности даже за рубежом. Отчасти задача решается методом аналогий.
Менее благополучно дело обстоит с внедрением бухгалтерских модулей.
Какую экономическую выгоду получит предприятие, если заменит “плохую” бухгалтерскую систему на “хорошую”? Например, повышение качества учета. Адекватная бухгалтерская система “организует” работающего в ней бухгалтера.
Знакомясь с учетом клиента, нередко обнаруживаешь сотни фантастических субсчетов (заменяющих аналитику), диковинные отчеты, созданные под мудрым руководством, какой-нибудь Марьи Ивановны. Все это согласовано с представителем налоговой инспекции и гордо именуется “официальной учетной политикой предприятия”.
Установка на таком предприятии хотя бы “1С” ведет к уничтожению существующей бухгалтерской “матрицы” и вносит некоторый учетный порядок. Однако единственный аргумент в пользу внедрения – необходимость полностью перестраивать учет в случае ухода “концептуального главбуха”.
Понятно, что консультант, указавший такие причины, автоматически оказывается в конфронтации с главным бухгалтером. А это, мягко говоря, не полезно.
На первый взгляд, значительно проще обстоит дело с взаиморасчетами (поставщики, покупатели, авансы, дебиторы, кредиторы и т. д.). Три основных аргумента в пользу автоматизации:
– уменьшается вероятности ошибки (особенно если расчеты многовалютные);
– руководство в любой момент имеет доступ к исчерпывающей информации о положении дел;
– существует возможность в режиме реального времени отслеживать должников и своевременно принимать меры.
Однако и тут не все гладко. Чтобы количественно оценить потери от ошибок, надо заранее получить полную информацию по клиенту и его финансовой истории. До подписания договора это нереально. Ущерб от несвоевременных действий вследствие недостатка информации (как и прибыль – в обратном случае) расчету практически не поддается.
Многие так называемые “точные данные” приводятся ИТ-компаниями в основном для психологического эффекта. Общие слова и цифры, результаты статистики вряд ли могут произвести на руководство заказчика сильное впечатление.
Организация проекта
Существуют три уровня организации проекта (для больших предприятий):
Управляющий комитет (руководитель компании и его заместители). Регулярные совещания 1-2 раза в месяц. Определяет стратегию, ресурсы, принимает основные решения.
Рабочий комитет (менеджеры высокого уровня). Совещания – раз в неделю. Вырабатывает политику, предлагает решения наиболее важных проблем, отслеживает результаты. Координатор команд (в малых фирмах не нужен). Решает вопросы, требующие согласования позиций групп.
Рабочая команда по внедрению (6-7 специалистов из разных областей). Разбивается на логические группы по подразделениям, производственным направлениям и программам. Осуществляет контроль на уровне фирмы и ее отделов. Члены команд могут работать над отдельными задачами.
Важнейшая цель организации проекта – вовлечение сотрудников компании-клиента в процесс внедрения. Это достигается через распределение ответственности. Персонал отвечает за автоматизацию своих участков.
Оптимальная структура рабочей команды:
сотрудник (сотрудники) заказчика, работающие на данном участке. Задачи: консультировать ИТ специалистов, осуществлять текущий контроль и предварительную приемку внедряемых объектов (формы, документы, отчеты и т. д.);
сотрудник (сотрудники) отдела информационных технологий (ОИТ) заказчика. Задачи: освоить в необходимом объеме инструментальные средства исполнителя (“1С”, “Галактика”, Scala, R3 и др.), участвовать в доводке и разработке автоматизированной системы, служить информационным “буфером” между сотрудниками клиента и консультантами исполнителя;
консультанты-программисты исполнителя. Задачи: разработать, внедрить, адаптировать необходимые модули, консультировать сотрудников ОИТ заказчика.
Использование в разработке и внедрении сотрудников ОИТ компании-клиента – не просто важный, а необходимый шаг. От него во многом зависит успех автоматизации.
Причины:
сотрудники ОИТ так или иначе уже проводили автоматизацию своего предприятия и обладают ценным “know-how”, которым на уровне диалога делиться, скорее всего, не станут;
действительно хорошо освоить систему сотрудники могут, принимая непосредственное участие в ее разработке или настройке. В противном случае они останутся только продвинутыми пользователями и окажутся в неблагодарной роли передаточного звена между заказчиком и исполнителем.
Многие компании проводят успешную автоматизацию сравнительно крупных предприятий, привлекая к проекту не больше двух-трех своих консультантов. При этом ИТ-специалисты заказчика проходят предварительное обучение и могут выполнить основной объем работ на этапе настройки (кодирования). Консультантам остается осуществлять “чуткое руководство” (что тоже весьма непросто) и разбираться с тонкостями и сложностями процесса.
Если ИТ-специалисты заказчика к внедрению не привлекаются, стоит заключить долговременный договор на сопровождение и доработку системы.
Выработка целей
Выработка целей предусматривает четкое определение и описание качественных и количественных ожидаемых результатов проекта. Это краткая формулировка эффекта, который руководители надеются получить от вложения средств в автоматизацию.
Как уже говорилось, расчет ROI (коэффициент эффективности инвестиций) для проектов по автоматизации вызывает значительные трудности даже в наиболее “продвинутых” странах. Цели не определяются с точки зрения чисто финансовой выгоды, а связываются с появлением новых источников информации или получением качественного экономического эффекта.
Например, данные управленческого учета, необходимые руководителям для принятия решений, могут “пылиться” где-нибудь в экономическом отделе, который раз в квартал будет “на коленках” составлять никому не нужную отчетность. При этом создание автоматизированного хранилища не финансируется. Причина: нужная информация уже есть, и целый отдел с ней “работает”.
Данные, как товар, не должны просто лежать где-то в компании. Их надо довести до конечных пользователей, причем желательно – пока данные свежие.
К счастью, большинство российских компаний уже осознали, что информация является одним из основных ресурсов предприятия, и рассматривают ее как важнейший элемент стратегического развития.
“Клиент готов”
Итак, руководство ознакомлено с деталями проекта, осознает его цели и готово активно участвовать в предстоящей работе. Общая схема функционирования компании определена, бизнес-процессы расписаны, положение дел на предприятии прояснено, договор утвержден, и служащие уже с нетерпением ожидают прихода “внедренцев”.
Одним словом, можно приступать ко второй фазе автоматизации. Она также состоит из нескольких этапов.
Технический проект
Технический проект (техническое предложение, ТП) – это набор документов и спецификаций, описывающих конструкцию, архитектуру, устройство и состав как системы в целом, так и отдельных ее модулей.
В основе технического проекта лежит техническое задание (о котором говорилось выше). Он содержит результаты детального проектирования, спецификации каждого компонента, интерфейсы между компонентами, требования к тестам, план интеграции компонентов.
В российской практике результаты предпроектного обследования, техническое задание и технический проект часто сводятся в один документ (техническое задание). Реализация описываемого плана в полном объеме предполагает, что в этом случае данные будут хотя бы тематически разделены.
Начальная переподготовка
Цель начальной переподготовки – обучение персонала, который затем будет работать над внедрением системы.
В первую очередь, следует определить предметных экспертов – сотрудников компании-заказчика, которые знают автоматизируемый участок лучше, чем кто-либо другой, и смогут стать лучшими преподавателями.
Большое значение имеет переподготовка по обеспечению необходимой точности данных (см. ниже “Управление данными”).
Планирование
Как правило, на предприятии существуют два плана автоматизации: стратегический и оперативный.
Стратегический план содержит базовые принципы, в том числе:
цели;
способ автоматизации (комплексная, кустовая и т. д.);
долгосрочную техническую политику (стандарты и т. д.);
ограничения (финансовые, временные и т. д.).
Стратегия автоматизации должна соответствовать общей стратегии бизнеса.
В некоторых компаниях с большим успехом использовался подход, связанный с определением критических факторов успеха. Эти факторы часто не совпадают с целями и задачами организации.
Например, стратегическими задачами предприятия, работающего в автомобильной промышленности, являются: рост производства, капитализация, ввод новых мощностей, перенос части производства в другие регионы. Эти задачи определят стратегический план автоматизации.
Критическими факторами успеха для того же предприятия могут быть: экономия топлива, усовершенствование дизайна автомобиля, эффективная организация торговли, жесткий контроль за стоимостью изготовления. В плане автоматизации этим моментам также должно быть уделено значительное внимание.
Критические факторы успеха целесообразно пересматривать раз в три месяца. Соответственно, важно своевременно корректировать и стратегический план автоматизации.
В оперативном плане определяются основные этапы автоматизации и сроки их реализации (переподготовка, внедрение новых алгоритмов управления данными, переход на новую систему и т. д.).
Управление данными
Уайт делит данные на первостепенные и второстепенные. В первостепенных данных неточность недопустима. Второстепенные позволяют некоторый разброс параметров.
Приведем примеры управления данными в различных областях автоматизации.
Управление производственными запасами (MRP). Входные данные:
Контрольный график. Показывает, какие конечные продукты будут произведены, когда они потребуются и в каком количестве. Как правило, составляется на основе требований, а не возможности, поэтому начальный график не всегда выполним.
Файл списка материалов. Содержит перечень всех узлов, подузлов, деталей и сырьевых материалов, необходимых для производства одной единицы конечного продукта. Минимальная точность данных – 98%.
Файл данных по материально производственным запасам. Используется для хранения информации о состоянии каждого элемента производства. Минимальная точность – 95%.
Торговля (упрощенный вариант управления запасами). Входные данные:
Планируемые объемы продаж.
Данные по номенклатуре товаров. Требуют максимальной точности. На всех складах и в подразделениях необходимо использовать единый иерархический справочник продукции. Механизмы изменения, добавления и удаления элементов справочника следует строго регламентировать. Любая ошибка приведет к труднообратимым последствиям и дополнительным психологическим сложностям.
Пример. Оператор не слишком уверенно работает со справочником товаров. Не найдя нужного наименования, он добавляет новый элемент, который отличается от искомого, скажем, одним пробелом (“водка особая” – “водка особая”). После чего оформляется поступление товара на склад.
Результат: на складе числится недостача, хотя на самом деле получение отражено. Вывод? Компьютер “напутал”. Сотрудники перестают верить программе, и во всех последующих бедах автоматически оказывается виноват компьютер.
Если ошибка не выявлена сразу, она может привести к полному хаосу (по мере отражения новых приходов и расходов).
– Данные по материально-производственным запасам. К ним относится информация по запасам на складах, товарам в пути, браку, товарам, отданным на реализацию, планируемым закупкам. Требуется высокая точность. Наиболее распространенная ошибка – хронологически неверный ввод документов.
Пример. Данные о разгрузке фуры задерживаются, хотя товар на склад уже поступил. Клиент торопит. Дилемма: побыстрее обслужить клиента или ждать прихода выверенных данных. Нередко выбирается первое. Некоторые фирмы ухитряются постоянно работать с отрицательным остатком на складе. Приход товара оформляется, “когда есть время” (отгрузка – вот настоящая работа, которую надо своевременно выполнять!).
Чтобы организовать эффективное управление данными, следует:
провести переподготовку персонала (объяснить сотрудникам, почему необходима требуемая точность данных);
создать систему персональной ответственности;
обеспечить контроль.
Это самый трудоемкий этап внедрения.
Параллельное внедрение
Новые технологии целесообразно внедрять параллельно в различных областях производственной деятельности (бухгалтерия, кадры, производство, контроль качества, САПР и т. д.).
Сокращается общее время внедрения, возрастают интеграционные возможности модулей. Проведение интеграции на раннем этапе значительно уменьшает трудоемкость работ.
Выбор системы
В России этот этап имеет свои особенности. Как правило, проект по внедрению реализует поставщик конкретного программного обеспечения, так что речь о реальном выборе не идет. Однако в последнее время увеличился спрос на услуги консалтинговых фирм, не “привязанных” к конкретной системе. Их подход более объективен. Они не стремятся выполнить план продаж определенного продукта и могут сосредоточиться на исследовании бизнес-процессов и поиске средства повысить эффективность работы предприятия.
Безусловно, многое зависит от конкретных участников проекта. Помню случай, когда компания, продвигающая R3, проанализировав деятельность предприятия-заказчика (представитель автомобильной промышленности), предложила ему установить систему Baan. В то же время так называемая “независимая консалтинговая компания” активно “впаривала” всем подряд ПО конкретного производителя, который ей за это приплачивал.
Ввод в эксплуатацию
Есть несколько способов приступить к использованию новой системы:
Параллельная стратегия. Одновременная работа вручную, на “старой” системе и на внедренной. Результаты постоянно сравниваются, новая система адаптируется. Недостаток – значительные трудозатраты (вследствие дуюлирования), большие сроки внедрения.
Скачок (шоковая терапия). “С понедельника работаем на новой системе!” Эффективно, но иногда приводит к провалу.
Опытная эксплуатация пилотного проекта. Скачок в рамках одного производственного участка. Такой пошаговый запуск наиболее надежен, существенно снижает риск неудачи.
Узкое место. Автоматизация самого “узкого” производственного места с постепенным расширением области автоматизации.
Этапы развития функциональности
Независимо от способа ввода в эксплуатацию, достижение максимальной функциональности системы обычно проходит в несколько этапов:
Создание прототипа (прототопирование). Под прототипом понимается набор программ, моделирующий в общих чертах работу системы. Прототип демонстрируется сотрудникам заказчика, чтобы они могли ознакомиться с системой, внести свои предложения относительно функциональности.
Создание рабочих проектов. Рабочий проект – система с неполной функциональностью, на которой, тем не менее, можно проводить основные операции и обучение.
Разработка и внедрение. Функциональность доведена до оптимального состояния, система готова к эксплуатации.
Оценка результатов
Получение “обратной связи”: результаты деятельности системы сравниваются с целями, сформулированными на начальном этапе и скорректированными в процессе внедрения. Данный этап позволяет понять, насколько успешен проект внедрения.
Анализ текущего состояния
Анализ текущего состояния выявляет, какие задачи, процессы выполнены эффективно, какие требуют изменений и доработок; обеспечена ли необходимая точность данных.
Постоянная переподготовка
Переподготовка не завершается после внедрения системы. Она должна проходить регулярно.
Старый добрый ГОСТ
Сейчас нередко звучат призывы активнее обращаться к старому доброму ГОСТу, а не выдумывать какие-то новые сомнительные методики внедрения.
Несомненно, придерживаться стандартов полезно, но, на наш взгляд, существующий ГОСТ 34.601-90 (от 1992 г) не может служить эффективной методологией. Слишком сильно в нем влияние социалистической, плановой экономики. Кроме того, он чересчур универсален.
Рассмотрим содержание отечественного ГОСТа ТЗ 34.601-90 “Автоматизированные системы стадии создания” (дата введения 01.01.1992 г.).
Стандарт распространяется на автоматизированные системы (АС) для различных видов деятельности (исследование, проектирование, управление и т. п.), в том числе на их сочетания, создаваемые в организациях, объединениях и на предприятиях.
Устанавливаются следующие стадии и этапы создания АС:
формирование требований к АС;
разработка концепции АС;
техническое задание;
эскизный проект;
технический проект;
рабочая документация;
ввод в действие;
сопровождение АС.
По аналогии с планом Уайта, первые три пункта резонно отнести к нулевому этапу проекта.
Формирование требований и разработка концепции
Формирование требований к АС включает в себя:
обследование объекта и обоснование необходимости создания АС (сбор данных об объекте автоматизации и видах деятельности, оценка технико-экономической, социальной и др. целесообразности создания системы);
формирование требований пользователя к АС (характеристика объекта автоматизации, описание требований к системе).
Разработка концепции предполагает:
изучение объекта (“детальное изучение объекта автоматизации и необходимые научно-исследовательские работы, связанные с поиском путей и оценкой возможности реализации требований пользователя”);
проведение необходимых научно-исследовательских работ;
разработку вариантов концепции АС, удовлетворяющих требованиям пользователя.
Некоторые комментарии
Что бросается в глаза в первую очередь? Требование проводить оценку целесообразности уже на первом этапе обследования. Это напоминает советское время, когда автоматизация отделов и структур предприятия осуществлялась “планово-хаотически”: решения принимались заранее и последующие обоснования фактически были отпиской.
Очевидно, что принять обоснованное решение о целесообразности внедрения можно только после полноценного исследования, проведенного в рамках работ нулевого этапа.
В тексте стандарта используется термин “объект автоматизации” (“изучение объекта автоматизации”, “требования к объекту автоматизации” и т. д.). Однако под таким объектом можно понимать структуры предприятия, а можно – его бизнес-процессы.
В зависимости от этого, участники проекта ориентируются либо на “структурный” (малоэффективный), либо на “процессорный” подход (что далеко не одно и то же).
Формирование требований и разработку концепции можно (с некоторой “натяжкой”) отнести к предпроектному обследованию. В первом случае процессы предприятия описываются “как есть”, во втором – “как будет”.
В комментариях к пункту “Обследование и оценка необходимости” перечислены требования, определяемые заказчиком: “ограничения допустимых затрат на разработку, ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия создания и функционирования системы”.
Ограничения затрат и эффект от системы стоит, наверное, отнести к разделам “Технико-Экономическое Обоснование” (ТЭО) и “Выработка целей”. Определить их корректно на первом этапе все равно не удастся.
На последней стадии разработки концепции стандарт предлагает в общем случае создавать альтернативные варианты и планы их реализации; оценивать преимущества и недостатки этих вариантов, а также объем необходимых средств.
Как нам кажется, столь масштабные исследования можно было проводить лишь в неторопливые времена развитого социализма. К тому же, не совсем понятно, о каких концепциях идет речь и по какому критерию эффективности их надо сравнивать.
Таким образом, в первых трех пунктах ГОСТа, которые мы отнесли к нулевому этапу, относительно четко описаны только две стадии: Предпроектное обследование и Техническое задание.
Следующие пункты относятся непосредственно к процессу внедрения.
Эскизный проект, технический проект, рабочая документация
Создание эскизного проекта включает:
разработку предварительных проектных решений по системе и ее частям;
разработку документации на АС и ее части.
Этот этап является фактически предварительной фазой построения технического проекта. Оно предполагает:
разработку проектных решений по системе и ее частям;
разработку документации на АС и ее части;
разработку и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) по их конструированию;
разработку заданий “на проектирование в смежных частях проекта объекта автоматизации”.
В рамках формирования рабочей документации предусмотрены:
разработка рабочей документации на систему и ее части;
разработка или адаптация программ.
Ввод в действие, сопровождение
Ввод в действие – самый емкий раздел ГОСТа. В него входят:
подготовка объекта автоматизации к вводу АС в действие;
подготовка персонала;
комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);
строительно-монтажные работы;
пусконаладочные работы;
проведение предварительных испытаний;
опытная эксплуатация;
проведение приемочных испытаний.
В последовательности, представленной в ГОСТе, можно обнаружить элементы управления данными. Предусмотрены классификация и кодирование информации (“Разработка проектных решений по системе и ее частям”), внедрение классификаторов (“Ввод в действие”), загрузка информации в базу данных и проверка ведения этой базы (“Пусконаладочные работы”).
В этот довольно ограниченный список действий не входят: определение точности данных, контроль, общая классификация и т. д.
На подготовку персонала выделен всего один пункт, чего явно недостаточно.
Этапы Опытный пример, Получение результата, Анализ текущего состояния отражены в процессе “Ввод в действие” сравнительно полно:
предварительные испытания;
опытная эксплуатация;
приемочные испытания.
Сопровождение АС включает:
выполнение работ в соответствии с гарантийными обязательствами;
послегарантийное обслуживание.
Выводы
Недостатки стандарта:
ГОСТ ТЗ 34.601-90 не ориентирован на конкретный вид программного продукта. В нем не учтены особенности внедрения комплексных систем автоматизации предприятия (особенно – в области обучения персонала и управления данными). Многие понятия определяются слишком широко.
ГОСТ содержит рудименты “планово-социалистического” подхода к управлению предприятием. Нулевой этап внедрения плохо проработан. Отсутствует этап предварительной переподготовки. Неубедительно и непоследовательно сформулированы процессы Выработка целей и ТЭО.
Стандарт имеет и ряд достоинств. В частности, хорошо проработана технологическая цепочка: Обследование – Техническое задание – Технический проект и Опытный Пример – Получение результата – Анализ текущего состояния. Это универсальные элементы внедрения, необходимые для автоматизации во всех областях деятельности.
ГОСТ – открытый, публично доступный стандарт внедрения. Несмотря на все недостатки, он превосходит по качеству многие “уникальные” и “эксклюзивные” методики.
Знающему достаточно
В последней части статьи хотелось бы рассмотреть внедренческие методики некоторых ИТ-компаний. Мы не ставим целью подвергнуть критике эти разработки (как и прорекламировать их). Основным источником послужили сайты и общедоступные материалы рассматриваемых фирм.
Не исключено, что в недрах уважаемых компаний хранятся пухлые фолианты, посвященные внедрению и предназначенные для служебного пользования. Не имея доступа к этим документам, мы не претендуем на полное знание реального процесса и анализируем планы, представленные на широкий суд потенциальных пользователей систем.
При том что методология внедрения является такой же интеллектуальной собственностью, как и сама программа, было бы странно, если бы компания-производитель скромно замалчивала свои достижения в этой области.
Scala
Фирма Scala представляет свою методологию внедрения Signature. Особо подчеркивается основная идея: участники проекта действуют как единая команда.
Процесс внедрения включает шесть этапов:
анализ;
организация проекта;
настройка системы;
подготовка данных;
тестовое испытание системы;
сдача проекта.
Первые два этапа можно отнести к нулевой фазе эталонного плана проекта (см. 1 часть статьи). “Анализ” аналогичен “Предпоектному обследованию” с естественным для него изучением требований бизнесс-процессов.
“Организация проекта” включает несколько пунктов эталонного плана. Выдержка из описания: “…составляют план проекта, в котором определены сроки проекта, его участники и бюджет. На данном этапе создается рабочая группа проекта, которая состоит из консультантов Scala и основных пользователей системы. Также назначаются руководители проекта со стороны клиента и компании Scala. Для больших проектов создается управляющий комитет, в обязанности которого входит контроль за проведением проекта от начала до конца”.
Здесь можно выделить (с некоторым допущением) элементы “ТЭО”, “Выработки целей” и собственно “Организацию проекта”. Не упоминается составление Технического задания. Как это часто бывает, не представлена “Предварительная переподготовка”.
Следующие этапы относятся непосредственно к внедрению. Не приводя исходного текста методологии, ограничимся некоторыми комментариями.
Этап 3:
настройка системы;
создание прототипа;
создание руководства пользователя;
обучение.
Удивительным образом игнорируется такой немаловажный документ, как Технический проект. Возможно, он неявно предусмотрен в пункте “Прототопирование”.
Этап 4:
подготовка данных;
перенос, конвертация, загрузка данных в систему Scala;
проверка результатов (например, входящее сальдо и аналитика).
Этап 5:
тестовое испытание системы.
Этап 6:
сдача проекта;
аудит системы;
проверка подготовленной в рамках проекта документации;
передача проекта группе ключевых пользователей.
Заключение: “Наша главная задача – совместно с клиентом, используя методологию внедрения Signature, достичь поставленной цели в срок и в пределах запланированного бюджета”.
Сильные стороны приведенного плана:
много внимания уделяется эффективной организации проекта, взаимодействию заказчика и исполнителя;
подробно расписан этап предварительного обследования;
выделена в отдельный пункт работа с данными (что бывает нечасто).
Недостатки:
не упомянуты Техническое задание и Технический проект;
недостаточно времени отводится на обучение;
ничего не говорится о классификации данных на концептуальном уровне и проектировании процессов с точки зрения точности данных.
1С-Рарус
Задача фирмы – “разработка и внедрение продуктов 1С и оригинальных конфигураций, созданных на платформе 1С”.
Компания высоко оценивает собственный план: “Специалисты внедренческого центра 1С-Рарус разработали уникальную технологию внедрения, которая позволяет максимально сократить время от приобретения программного продукта до начала его эффективного использования”.
Методика предусматривает следующие этапы:
предварительное обследование;
составление перечня работ и план-графика его исполнения;
конфигурирование;
тестирование и ввод в эксплуатацию;
сопровождение.
В первом пункте приводится сравнительно подробное описание стандартного предпроектного обследования.
Второй раскрывается следующим образом: “По построенной ранее на этапе предварительного обследования модели автоматизации подготавливается подробный перечень работ. Каждый его пункт детально обсуждается и согласовывается с заказчиком. План-график отражает согласованные сроки выполнения каждого пункта перечня работ”.
Как можно предположить, имеется в виду некое сочетание Технического задания, Технического проекта и Календарного плана.
Конфигурирование: “Основной по продолжительности этап внедрения, на котором производится модификация “1С:Предприятия” в соответствии с разработанным и согласованными ранее перечнем работ в сроки, определенные в плане-графике. Может быть разбит на несколько промежуточных, каждый из которых контролируется, тестируется и сдается отдельно”.
В процессе тестирования и ввода в эксплуатацию на созданной конфигурации отрабатывается тестовая задача с полным циклом документооборота. На том же этапе: проводится обучение персонала, составляется описание конфигурации и руководства пользователя, при необходимости осуществляется подготовка сети и оборудования.
Не осмелимся усомниться, что “уникальная” методика 1С-Рарус обеспечивает успешность многочисленных внедрений фирмы, однако часть ее, представленная на сайте, не слишком впечатляет.
Компания является весьма “раскрученной” в своей ценовой нише. Она одной из первых (если не первой) создала на платформе 1С модуль “Производство” (цена за одно рабочее место – более 500 долларов).
Услуги специалистов 1С-Рарус не дешевы. По собственному опыту: работа постановщика и программиста по доработке упомянутого модуля была оценена в 10 000 долларов за два месяца. Правда, за эту сумму нам обещали действительно классных профессионалов.
В компании проводятся семинары по MRP и MRPII и сертификация специалистов в этой области.
В свете всего перечисленного тем более удивительно, что план внедрения, состоящий, в сущности, из предпроектного обследования, техпроекта, каландарного плана и конфигурирования анонсируется как уникальное интеллектуальное достояние фирмы.
Обучение предусмотрено лишь на этапе тестирования, управление данными вообще не упоминается. Такая методика может работать только на очень маленьких проектах, да и то с оговорками.
При этом именно 1С-Рарус особо акцентировала внимание на вопросах качества, отметив что контроль качества ведется на протяжении всего проекта. В компании существует специальное подразделение, которое занимается этой проблемой. Фирма планирует получить сертификат ISO 9001.
ЭпикРус
Методику внедрения ЭпикРус можно назвать наиболее проработанной из тех, с которыми мы ознакомились в ходе исследования. Специалисты этой компании плодотворно потрудились, выложив на сайт столько информации, что для ее анализа надо писать отдельную статью.
Согласно концепции фирмы, полномасштабное внедрение включает:
фазу предпроектного обследования (анализ информации и выходных документов);
фазу принятия административных решений по проекту (системный анализ, установка ПО, обучение специалистов, руководство проектом и обеспечение качества);
фазу проектирования (предварительное проектирование, обсуждение и моделирование, окончательный дизайн системы);
фазу внедрения (конфигурирование пакета, функциональная адаптация, тестирование системы, пользовательские инструкции, доработка процедур и обучение, подготовка производственной среды);
фазу перехода на новую систему (поддержка пользователей, “тонкая” настройка системы, дополнительные работы, обзор состояния после перехода, результаты внедрения продуктов).
Трудно сказать, готов ли потенциальный заказчик (не специалист) “переварить” столь широкий объем информации. Однако имидж серьезной и основательной организации, бесспорно, создать удалось.
Преимущества методики: большое внимание уделено обучению персонала заказчика; предусмотрена пресловутая Предварительная переподготовка (на которой так настаивал Уайт и которая игнорируется большинством компаний); присутствует этап Организации проекта (также забытый многими российскими фирмами).
Недостатки: не выделены в особые этапы Обработка данных и создание ТЭО; не всегда определяются выходные документы этапов (ТЗ, ТП).
Некоторое недоумение вызвала информация о том, что предпроектное обследование формализуется в нотации SADT. По статистике SADT используют для описания бизнес-процессов в 10% случаев, а в 90% – DFD. Это связано с тем, что SADT изначально создавали для описания производственных процессов, а не моделей информационных систем.
Так или иначе, методику ЭпикРус можно определить как наиболее проработанную и обстоятельно изложенную. Допускаем, что свой вклад в успех внесла PR-служба компании.
С. В. Пищиков, project manager, “Ш.ЭЙР-С” piswik@online.ru
