2002

статья была опубликована на www.axforum.info

Михаил Ковалев

 

 

Некоторые вопросы внедрения приложений. Часть 1.   

 


 

 Причины появления документа

Это попытка систематизировать и обобщить опыт (положительный и отрицательный), полученный при внедрении систем корпоративного учета NS2000, AXAPTA Navision.

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

PS
С удивлением “вдруг” обнаруживаешь, что к тем же результатам и гораздо раньше пришли многие другие. Но когда до тебя доходит информация, о том, что на “те же грабли продолжают наступать” столько же и даже больше, то хочется немного поделиться тем, что имеешь.

Данный документ - не методика “как внедрять системы” (или как “делать” проекты), и даже не методология. Это всего лишь “мысли вслух” (и не более) о том, как может быть организован процесс внедрения для достижения согласованного результата. За основу взяты идеи Application Implementation Method Oracle и рассмотены сквозь призму собственного опыта

Исходные данные

1. При создании документа использовались
• материалы
- Методология AIM Oracle
• опыт внедрения системы AXAPTA Navision в ГК “Счастливый кроха” в качестве менеджера проекта (2001- 2002, без использования услуг внешних консультантов)
• собственный опыт внедрения системы NS2000 (фирма Никос-Софт) в качестве менеджера проекта в организациях
- Главный Центр Радиовещания и Телевидения РФ г. Москва (1997-1998)
- Нижегородоргнефтесинтез - “НОРСИ” г. Кстово (1998-2001)
• знания о процессах внедрения в 2000-2001 NS2000 (фирма Никос-Софт) в организациях
- “Хелми” г. Барнаул
- “Лукойл-Белоруссия” г. Минск
- ‘’Гусь-Хрустальный Завод” г. Гусь-Хрустальный

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

3. Определения
• Бизнес-процесс – совокупность финансово-хозяйственных операций предприятия, логически объединенных в единое целое и представляющих часть деятельности предприятия (например, закупка товара)
• Бизнес-цепочка – составная часть бизнес-процесса (например,
бизнес-процесс – закупка товара;
бизнес-цепочка 1 – оприходование товара при его доставке автотранспортом;
бизнес-цепочка 2 – оприходование товара при его доставке ЖД транспортом)

Основные процессы при внедрении
Хочется отметить, что при внедрении разных систем одного класса в разных организациях. проявляются общие закономерности. Это касается и самих процессов, которые идут при внедрении, и их временных характеристик.
В методологии AIM выделяют следующую совокупность процессов

• Определение рабочих требований – что хочет получить Заказчик (или выполнение чего будет рассматриваться как успешное внедрение системы)
• Распределение рабочих требований - что уже существует в текущей функциональности системы и что сейчас отсутствует
• Планирование приложений и технической архитектуры – как это может быть реализовано
• Проектирование и Построение Модулей – создание дополнительной функциональности
• Конвертация данных – перенесение информационных объектов в приложение (справочники номенклатуры, организаций, банков и т.д. )
• Документирование
• Тестирование рабочих процессов – тестирование функций (например, заведение платежного документа, печать платежного документа и т.д.)
• Тестирование функционирования системы – реализация бизнес-цепочки (например в АХАРТА, создание заказа, привязка оплаты к заказу (сопоставление), создание накладной, создание счета-фактуры)
• Обучение
• Переход на новую систему

Контрольные точки (или этапы) проекта

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

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

Предлагаемый AIM подход к контрольным точкам представляется более продуктивным, т.к. допускает итерации в фазах (этапах) Анализ операций, Разработка решения. Действительно, при реализации проектов после проведения этапа Обследования при проведении этапа Внедрения во многих случаях де-факто идут процессы по уточнению технологии, формируются и/или уточняются требования к системе, т.к.
• Исполнителю, с одной стороны, в оговоренные сроки и имеющими ресурсами (их количественным и качественным составом) не удается охватить с требуемой точностью детализации все участки работ
• Заказчик, c другой стороны, не всегда с требуемой степенью детализации понимает, чего же он сам хочет получить (!!!)

Продолжение следует
М.Ковалев


 

СТАДИИ РЕАЛИЗАЦИИ ПРОЕКТА

1. Определение стратегии внедрения
Включает фазы:
• Переход от продажи к внедрению
Цель:
- Выявление “ключевых” пользователей системы
- Разработка организации проекта
Формирование рабочей группы у Исполнителя, назначение менеджера проекта;
Формирование рабочей группы у Заказчика, назначение менеджера проекта, определение и констатация его полномочий, постановка вопроса о необходимости выделении администраторов системы (системного и прикладного).

• Установка и согласование целей, задач и границ проекта
Цель:
- Определение ожидаемых результатов проекта (что получит Заказчик): обследование и описание существующих бизнес-процессов (как организация работает сейчас); моделирование возможности отражения существующих бизнес-процессов в системе;
- Согласование предложений (Что есть у Заказчика сейчас и что будет потом)
- Согласование терминологии (должны “разговаривать” на одном языке)
- Согласование предполагаемых объемов работ (затрагиваем такие и такие участки работ в вашей организации)
-Оценка потенциальных рисков

• Формирование плана проекта
Цель:
- Сформировать представление, о том как, каким образом Исполнитель будет работать с Заказчиком исходя из предполагаемого объема финансирования проекта
- Поставить и согласовать с Заказчиком вопросы о том, какие работы и в какие сроки будут проводиться для достижения планируемого результата
- Очертить потенциальные опасности и степень их риска

Планируемые результаты
- должно быть сформировано у Исполнителя о бизнесе Заказчика адекватное представление
- должен быть сформирован детальный план работ по внедрению системы

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

На какие вопросы должны быть получены положительные ответы
От Заказчика системы (решения) Исполнитель ожидает получить ответ
- правильно ли представители Исполнителя понимают бизнес Заказчика
От Исполнителя Заказчик прежде всего ожидает получить ответы на вопросы
- как, каким образом будет осуществляется процесс внедрения системы
- что будет делаться (этапность работ) в какие сроки и за какие деньги

Продолжение следует
М.Ковалев

 

Некоторые вопросы внедрения приложений. Часть 3.


 

2. Анализ и разработка решения

Фазы анализа:
• Детализация информации о существующих бизнес-процессах
Цель
- изучение текущего состояния бизнеса на конкретных участках
- формирование спика задач, которые решаются на конкретных участках
- сбор сведений о специфике работы на конкретных участках (например, в бухгалтерии участок расчетов с подотчетниками)
- выделение бизнес-цепочек из бизнес-процессов
- изучение информационных объектов (где и как хранится информация, ее “качество”)

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

• отображение существующих в организации бизнес-процессов на существующую функциональность системы (“mapping”)
Цель
- оценить возможность использовать/настроить в системе бизнес-процессы Заказчика, происходящие на конкретном участке
- оценить совокупность (набор) модулей системы и требования к их функциональности, которые будут использоваться для решения задач на конкретных участках (например, на участке работы “Авансовые отчеты” могут быть задействованы функции модулей – Касса, Авансовые отчеты, Заказы, Закупки )
- оценить возможности использовать и/или настроить Экранные формы
- оценить возможности использовать и/или настроить Печатные формы
- оценить возможности использовать и/или настроить Отчет

• формирование предложений по изменению технологии работы Заказчика и/или изменения функциональности приложения

• обследование информационных объектов
- изучение информационных объектов
- изучение возможности перенесения информационных объектов в систему
- изучение возможности автоматического занесения информационных объектов в систему

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

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

Документы
Представляется целесообразным в документах отобразить
- Существующие бизнес-процессы (как есть сейчас)
- Будующие бизнес-процессы (как будет, как будет реализовано в системе )
- Техническое задание на систему (решение) и/или список доработок функциональности системы

Продолжение следует
М.Ковалев

 

 
3. Построение решения (создание версии системы клиента) и документирование

Построение решения включает
• Создание и утверждение технологии работы в системе (кто, что и как будет делать в системе)

•Завершение реализации недостающей функциональности
- уточнение постановки задачи
- кодирование
- тестирование
- согласование с Заказчиком в соответствии с ТЗ и/или ВшС полученой функциональности **
**PS: В случае неадекватного результата созданной функциональности требованиям бизнес-процесса (бизнес-цепочки) мы возвращаемся на фазу Анализа. В этой итерации могут быть проблемы с оценкой допустимых трудозатрат по “удовлетворению” Заказчика, выходом из цикла “удовлетворения” клиента

• Настройку каждого модуля
Для каждой бизнес-цепочки осуществляется
- ее реализация в существующей функциональности модуля
- интеграция вновь созданной функциональности
- тестирование бизнес-цепочки

• Интегрирование стандартных модулей в единое рабочее пространство (реализация бизнес-процесса)
• Разработка полного плана тестирования (сценарий тестирования) системы
• Проведение тестирования модулей и системы в соответствии с ожиданиями и эксплуатационными характеристиками
• Определение плана перехода от старой системы к новой путем распределения ролей поддержки бизнеса в старой и новой системах
• Обучение прикладных администраторов настройке системы по участкам работ

Ожидаемые результаты

• Завершенные и протестированные программы переноса данных и интерфейсов
• Протестированные программы отчетности Заказчика
• Протестированная специфика Заказчика
• Планы тестирования системы
• Подготовленная среда для тестирования
• Окончание тестирования приложений и проверка интеграции системы
• План ввода системы в эксплуатацию

Документация

Цель
• Обеспечение документацией для текущих и нестандартных ситуаций
• Обеспечений пособий для обучения пользователей

Продолжение следует
М.Ковалев

 

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

Требуемые мероприятия
Необходимо в ходе проводимых работ
• Подготовить ”эксплуатационное окружение” – прикладные и системные администраторы должны научиться уметь и проводить требуемые работы как в системе, так и с самой системой
• Провести обучение конечных пользователей
• Провести внедрение изменений как в процессах, так и в самой организации Заказчика – в процессе работ по внедрению системы де-факто идут процессы ре-инжениринга: в частности у конечного пользователя меняется характер работы, объем работы; часто меняются и сами функции.

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

Планируемые результаты
• Создание объективных предпосылок для отказа от использования новой системы, в том числе
- Наличие обученных пользователей
- Готовая операционная среда
- Завершение переноса данных в систему

•Отказ от использования старой информационной системы в части функций, реализованных в новой системе

• Решение руководителей Заказчика о переходе на новую информационную систему

Документы
- - - - - - - - - - - - -

Продолжение следует
М.Ковалев

 

 
5. Эксплуатация (Промышленная эксплуатация)
Цель
Поддержка бизнеса Заказчика путем отражения в системе приоритетных бизнес-процессов финансово-хозяйственной деятельности предприятия

Требуемые мероприятия
• Поддержание системы в работоспособном состоянии

• Аудит работы системы
- Контроль правильности функционирования
- Исправление ошибок

• Модернизация системы
- переход на другую версию системы
- расширение функциональных возможностей