В любом из перечисленных случаев встает вопрос о том, как организовать процесс внедрения системы, кто должен участвовать в проекте и какими силами можно этот проект выполнить.
Иностранные компании традиционно тяготеют к аутсорсингу всех непрофильных функций, в том числе и к передаче на субподряд проектов внедрения каких-либо систем. В российской практике принято создавать сервисные подразделения в составе предприятия. Это происходит по многим причинам, в числе которых можно назвать желание иметь требуемую компетенцию всегда под рукой, не переплачивая при этом за внешний сервис.
О какой же компетенции идет речь? Естественно, о компетенции в области инсталляции и конфигурации системы под задачи предприятия. Вот именно, "под задачи предприятия"! А как, кто и в каком виде их должен определить? Эта проблема зачастую является одной из ключевых проблем проекта внедрения системы.
Многие переносят практику создания моделей "Как Есть" (AS-IS) и "Как Будет" (TO-BE) на проект внедрения системы R/3. Это не совсем корректно, и вот почему.
Казалось бы, что логично построить проект внедрения следующим образом: центр компетенции (внутренний или внешний) проводит обследование предприятия, результатом которого является модель "Как Есть". Затем параллельно создается прототип будущей системы и модель "Как будет". После утверждения модели начинается фаза детальной реализации.
Данная схема работает с переменным успехом. Нам кажется, что она больше подходит для случая проектирования системы с нуля, а не для проекта внедрения пакета стандартных приложений.
Особенности внедрения "стандартной" системы SAP R/3 состоит в том, что этот пакет с концептуальной точки зрения представляет собой сложный комплекс заложенных в нем схем и понятий. За каждым термином (группа закупок, бизнес-сфера и т. д.) скрывается свое назначение и смысл.
Специалисты-предметники, представляющие различные функциональные подразделения предприятия, оперируют своей сложившейся системой понятий. И часто общеупотребимые в их деятельности термины в системе R/3 несут иную смысловую нагрузку. Это приводит к тому, что сформулированная в этих терминах задача не совсем "ложится" в систему.
Из этого следует принцип разделения ролей на этапе проектирования, главными из которых являются роли "Владельца процесса" (Process Owner) и "Эксперта по приложению" (Application Consultant).
Перед владельцем процесса стоит задача формирования требований к будущей системе. В конечном итоге эти требования должны быть сформулированы в терминах системы, или со ссылкой на те или иные объекты системы (элементы структуры предприятия, основных данных, функции и процессы).
Для решения этой задачи владелец процесса должен обладать определенным уровнем компетенции и оперировать основными понятиями в области своего приложения или модуля. Соответственно, предметному специалисту необходим определенный тренинг по функциональной части системы. Именно эту задачу и обслуживает комплекс курсов второго уровня (такие, как LO020 или AC040).
Данные курсы не затрагивают вопросы конфигурации системы, а дают лишь концептуальный обзор того или иного модуля системы, релевантных элементов структуры предприятия, основных данных, функций, процессов и отчетов. Подобный обзор сопровождается рядом упражнений, закрепляющих навыки выполнения стандартных транзакций. Именно такая учебная сессия для членов проектной группы - представителей функциональных подразделений предусмотрена на фазе "Подготовка проекта" в методологии ASAP. Аналогичные программы обучения предлагают и некоторые партнеры SAP AG.
Далее, в методологии ASAP предусмотрен ряд "семинаров" по определению требований к системе (включая детальное определение объема внедрения). В семинарах участвуют владельцы процессов и эксперты по приложениям. Последним предлагается для выявления и фиксации требований к системе использовать такой инструмент, как "База данных вопросов и ответов" (Questions & Answers Database). Аналогичным, но более мощным инструментом является Live Kit Structure, совместный продукт компаний Siemens и Chestra, который является составляющей методологии LIVE Method & Tools powered by ASAP.
Сначала проводятся семинары по определению структуры предприятия в R/3 и стандартов предприятия (стандарты нумерации основных данных и документов, принципы группировки и классификации различных данных, план счетов, объекты контировки и пр.). Стоит отметить, что методология ASAP считает такие задачи, как разработка плана счетов и формирование справочников "внешними" по отношению к проекту внедрения системы управления предприятием.
Далее проводятся семинары по определению требований к бизнес-процессам. Прежде всего определяется перечень тех стандартных бизнес-процессов, которые будут использоваться предприятием. Например, являются ли релевантными для предприятия процессы, связанные с управлением запасами возвратной тары и т. п.
На заключительном этапе определяются требования к формулярам и отчетам (layout sets and reporting requirements), определяются функциональные пробелы и требования к модификации и расширению системы (gaps, modifications and enhancements).
Стоит отметить, что в некоторых западных консалтинговых компаниях принята специализация на "процессных" консультантов и "конфигураторов". Первые участвуют в разработке концептуального проекта системы, вторые - настраивают систему в соответствии с заданными требованиями. В роли процессных консультантов зачастую выступают бывшие бизнес-пользователи, хорошо владеющие предметной областью. Конфигураторы помимо навыков настройки определенного модуля системы иногда владеют средствами разработки ABAP/4.
В отечественных проектах, напротив, помимо
функций определения требований и конфигурации системы консультанты иногда
участвуют в решении таких задач, как определение стандартов предприятия
(например, разработка плана счетов). Такие задачи не входят в рамки проекта
внедрения системы SAP R/3. Подробнее об этом - в одном из следующих материалов.
Copyright 2001 sappers.narod.ru