Наброски команды IT2B

[Елена Сысовская]

Координирование работ проекта.

ред.1 Сысовская, Найденов 15/09/01

Адрес проекта IT2B, на котором опубликован материал документа: it2b.h1.ru
Разработать детальный план внедрения.

Как у любого проекта, у него есть этапы планирования (предварительное и оперативное по ключевым показателям), организации, актуализации, регулирования, учета, анализа. Они касаются ресурсов и качества.

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

Состав детального плана.

Общий план работ должен содержать:

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

График платежей.

Составляется график платежей, связанных с приобретениями функциональных и пользовательских лицензий, консалтинговыми услугами, затратам на программирование и совмещение ПО. Необходимо выяснить – когда платить. Можно оплатить сразу первоочередной функциональный комплекс и необходимое на первое время количество рабочих мест. Можно оплачивать по мере внедрения блоков, докупая необходимые рабочие места. Если настройку проводит фирма – внедренец, то функциональные блоки можно оплачивать по мере их готовности к сдаче заказчику, после подписания акта сдачи – приемки. График закупки и продажи тех. средств. Смета расходов и график платежей, связанных с зарплатой и обучением персонала, занятого во внедрении. График платежей и регламент действий, связанных с поддержкой и развитием системы (обновления версий, отчетности, модулей совмещения с другими программами).

Составить сводный бюджет.

Общее управление.

Управление по целям.

Управление по показателям.

Управление рисками.

Общее управление изменениями и принятием решений.

Оперативное планирование.

Процессы контроля.

Организация поддержки жизненного цикла.

Необходимо понимать, что развитие ИС – непрерывный процесс. С момента внедрения системы запускается процесс ее модернизации, заканчивающийся действиями, связанными с переходом к новой информационной системе.

Конфигурационное управление.

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

Поддержка ПО для бизнеса

Поддержка вспомогательного ПО

Поддержка ТС

Управление данными

Поддержка документационного обеспечения, системы знаний и обучения.

Поддержка документационного обеспечения

Обеспечение актуальной документацией по стандартам, регламентам поддержки и руководств.

Связь модели ИС и модели бизнес – процессов.

Поддержка системы знаний и обучения.

Поддержка организационного обеспечения

Обеспечение квалифицированными сотрудниками, необходимыми для работы ИС.

Предусмотреть будущее.

На данный момент наблюдаются ряд тенденций в технологиях КИС. Это интеграция ERP – технологий с системами электронного бизнеса B2B и B2C. Можно точно сказать, что мы будем вынуждены перейти к использованию этих решений в течении максимум 2-х ближайших лет, но скорее всего раньше. Несвоевременный переход к использованию таких решений означает потерю конкурентоспособных свойств компании. Системы класса Аксапта поддерживают данные решения, однако в ближайшее время (1-2 года) могут появиться другие перспективные направления. Проект внедрения ИС рассчитывается на 2 года и в него необходимо включить план мероприятий по контролю за актуальностью ИС, контроля за жизненным циклом ИС, в котором будет два этапа – внедрение и деактуализация, возможно, наложенные друг на друга.

[Елена Сысовская]

Управление документированием

Адрес проекта IT2B, на котором опубликован материал документа: it2b.h1.ru

Тема обширная - необходимо прописывать. Это только наброски.

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


Определить состав документационного обеспечения

Модель ИС и структура данных.

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

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

Разработка плана документирования.

Построить систему контроля за качеством процесса документирования.

[Елена Сысовская]

Управление программными и техническими средствами

ред. 1 Сысовская, 08/09/01

Адрес проекта IT2B, на котором опубликован материал документа: it2b.h1.ru

Моделирование ИС - не рассматриваем этап

Актуализация ИС.


В ходе проекта могут быть использованы следующие стратегии:

- параллельное ведение работ до верификации корректности новой ИС – самый трудоемкий вариант.

- Настройка новой ИС, пилотный запуск на небольших объемах (но в комплексе) и переход к новой ИС, самый популярный вариант.

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

Перенос данных

Подготовка к тестированию

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

Тестирование

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

Опытно-актуальная эксплуатация.

Двойная нагрузка на пользователей – двойной ввод данных, обучение. Нагрузка на службу внедрения.

Доработка системы.

Интегрированный пилотный период – проверка полноты соответствия системы.

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

Система вводится в эксплуатацию по отдельным участкам учета или управления.

Составить план обеспечения программными и техническими средствами.

[Елена Сысовская]

Предложение по оргструктуре проекта внедрения.



В данном документе использованы материалы Frontestep Cis, Сергей Питеркин.

Адрес проекта IT2B, на котором опубликован материал документа: it2b.h1.ru

ред. 12/10/01

Предлагаем следующий порядок работы над оргсхемой:

Выбрать организационную схему внедрения.

Сформировать рабочую команду.

Определить состав команды

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

Спланировать изменение оргструктуры.

Определить содержание контрактов и заключить их.

Система контроля за обязательствами.

Заключить контракты с исполнителями проектов.

Построить схему управления вопросами, связанными с организационной структурой.

Управление обучением

Организация обучения.

Организовать обучение сотрудников, входящих в группу внедрения.

Организовать обучение членов группы поддержки.

Организовать обучение пользователей, занятых в процессе тестирования.

Организовать обучение сотрудников подразделений.

Разработка плана обучения.

Построить систему контроля за качеством процесса обучения.

Возможные проблемы и конфликты, а также способы их предотвращения


Выбрать организационную схему внедрения.

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

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

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

Два правила, действующие при любом варианте:

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

Определить состав команды

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

На данный момент просматриваются следующие этапы:

Выбор системы;
Проектирование и отладка модели БП и ИС на этапе ППО;
Настройка ИС.
Тестирование, инициализация, опытная эксплуатация ИС.
Сквозное управление проектом включает в себя общие функции, выполняемые в рамках каждого этапа:

Документирование;
Обучение;
Контроль, планирование и обеспечение стоимости и сроков;
Управление оргструкторой проекта – обеспечение, регламент, планирование, координация, контроль, анализ и пр. функции ;
Составление регламента ведения работ.


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

Спланировать изменение оргструктуры.

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

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

Система контроля за обязательствами.

Заключить контракты с исполнителями проектов.

Построить схему управления вопросами, связанными с организационной структурой.

Планирование.

Отчеты.

Контроль.

Управление рисками.

Управление производительностью.

Управление качеством работ и их соответствия целям.

Анализ проделанной работы и корректировка.

Управление обучением

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

Организация обучения.

Организовать обучение сотрудников, входящих в группу внедрения.

Организовать обучение членов группы поддержки.

Организовать обучение пользователей, занятых в процессе тестирования.

Организовать обучение сотрудников подразделений.

Эти сотрудники не входят в состав ИС, но необходимо предусмотреть связанные с ними затраты ресурсов.

Разработка плана обучения.

Построить систему контроля за качеством процесса обучения.





Возможные проблемы и конфликты, а также способы их предотвращения

Даже идеальный подбор персонала не избавляет от появления проблем и возникновения конфликтов в команде внедрения. Эти проблемы лежат прежде всего в области снижения мотивации и личной заинтересованности и приводят к потере эффективности и качества работ.

Высшее руководство предприятия должно декларировать высочайшую приоритетность проекта и заявить о полной поддержке команды проекта. Цели и задачи проекта в контексте решения критически важных для предприятия вопросов должны быть поставлены перед группой внедрения достаточно четко.

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

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

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

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

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

Вместе с тем моральное и материальное поощрение группы внедрения может стать источником других конфликтных ситуаций, как в пределах группы, так и при взаимодействии с другими подразделениями предприятия. Существует множество систем поощрений, которые можно использовать в целях повышения мотивации [4]. Любая из них должна быть тщательно взвешена с позиции ее влияния на работу группы.

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

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

[Елена Сысовская]

ПРОЕКТЫ ДОЛЖНОСТНЫХ ОБЯЗАННОСТЕЙ

Адрес проекта IT2B, на котором опубликован материал документа: it2b.h1.ru

1. ПРОЕКТ ДОЛЖНОСТНЫХ ОБЯЗАННОСТЕЙ IT - ИНТЕГРАТОРА.
2. ПРОЕКТ ДОЛЖНОСТНЫХ ОБЯЗАННОСТЕЙ МЕНЕДЖЕРА ПО ВНЕДРЕНИЮ ИС. 2
3. ПРОЕКТ ДОЛЖНОСТНЫХ ОБЯЗАННОСТЕЙ ТЕХНИЧЕСКОГО МЕНЕДЖЕРА ПРОЕКТА ПО ВНЕДРЕНИЮ ИС.
4. ПРОЕКТ ДОЛЖНОСТНЫХ ОБЯЗАННОСТЕЙ РУКОВОДИТЕЛЯ (АДМИНИСТРАТОРА) ПРОЕКТА ПО ВНЕДРЕНИЮ ИС.
5. ПРОЕКТ ДОЛЖНОСТНЫХ ОБЯЗАННОСТЕЙ ВЛАДЕЛЬЦА ПРОЕКТА ПО ВНЕДРЕНИЮ ИС.
6. ПРОЕКТ ДОЛЖНОСТНЫХ ОБЯЗАННОСТЕЙ ФУНКЦИОНАЛЬНОГО МЕНЕДЖЕРА ПО ВНЕДРЕНИЮ ИС.
7. ПРОЕКТ ДОЛЖНОСТНЫХ ОБЯЗАННОСТЕЙ ГЛАВНОГО ПРОГРАММИСТА ПРОЕКТА ПО ВНЕДРЕНИЮ ИС.

[Елена Сысовская]

Замечания к документу
"План предпроектного обследования предприятия."

ред 3.

Найденов Виталий.

Адрес проекта IT2B, на котором опубликован материал документа: it2b.h1.ru


Рассмотрим процедуру предпроектного обследования, как повторяющуюся в течение всего жизненного цикла (ЖЦ) информационной системы (ИС) предприятия. Соответственно, “предпроектной” процедура будет называться только в начале ЖЦ ИС. В дальнейшем, на каждом витке ЖЦ, процедуру можно называть, например, так - сбор и обработка информации об объекте управления, выработка прогноза об успешности реализации запланированных изменений. В соответствии с этим положением и будем стремиться создать план работ. Т.е. план работ должен быть достаточным как для предпроетного обследования, так и для управления изменениями ИС в течение ЖЦ. Для простоты и краткости, такой участок ЖЦ назовем ППО (предпроектное обследование). Тем более что работы, именно по предпроектному обследованию, скорее всего, будут содержать все необходимые операции для успешного управления изменениями ИС и в начале проекта и в течение ЖЦ. Просто в зависимости от планируемых изменений какие-то операции будут пропущены. Состав работ ППО может значительно отличаться в различных проектах. Хотя, укрупненно, перечень проектных операций, скорее всего, будет схож в большинстве проектов. Учитывая специфику текущего состояния предприятия, часть проектных операций ППО может быть отнесена к другим этапам проекта: формулировке технического задания, внедрению системы и т.д.

Продукты, получаемые на выходе ППО:

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

Формирование и утверждение проектной группы.
Формулировка причины возникновения необходимости внесения изменений (в рамках ППО - ввода в эксплуатацию новой ИС). Выявление сути текущих проблем.
Аргументы, которые приводит руководство компаний к решению построения ИС, зачастую не достаточно проработаны и являются списком симптомов, следствий, но не причин. В отличие от “целей автоматизации”, вырабатываемых в процессе подготовки и реализации проекта, формализованных, иерархически выстроенных с учетом знаний специалистов бизнеса и специалистов системы. Термином “причины автоматизации” назовем цели автоматизации с точки зрения руководства, точнее людей, финансирующих проект, как бы ни были они локальны и субъективны. По данным различных источников и собственного опыта - успешность проекта, в первую очередь, зависит от поддержки проекта руководством. Поддержка же проекта руководством зависит в значительной степени от того, насколько, по их мнению, цели автоматизации, сформулированные консультантом (группой внедрения), соответствуют их представлениям о причинах автоматизации. Сопоставление выявленных проблем, причин автоматизации, знаний консультанта о путях развития проекта, позволяет достичь конгруэнтности целей и причин. В процессе построения дерева целей проекта внедрения ИС, потребуется постоянная коррекция причин в умах руководства в сторону формулируемых целей, в случае их значительного расхождения. В итоге, заказчик должен быть уверен, что получает именно то, что он хотел, несмотря на то, что это его желание корректируется специалистами в ходе проекта. Данное положение позволит достичь успеха в реализации проекта. Не секрет, что неуспешными называют проекты, обеспечивающие автоматизированное управление БП, обеспечивающие функциональность, но не достигшие каких-то субъективных представлений о целях проекта со стороны заказчика.

Выявление причин, стимулирующих решение проблем.
Если во втором разделе мы ответили на вопрос “почему”, то в третьем разделе необходимо ответить на вопрос “почему сейчас?”. Что явилось причиной инициирования проекта именно в данный момент. Какие сроки отводятся на проект, точнее, по какой причине. Ответ на этот вопрос позволит аргументированно спланировать этапность работ. Создать у заказчика представление о необходимой последовательности работ. Некоторые работы заказчик может требовать выполнить в первую очередь, пропуская ненужные, с его точки зрения, но необходимые, с точки зрения качественного выполнения проекта. Приведение в соответствие требований заказчика и проекта позволит более точно согласовывать качество исполнения, а в конечном итоге и успешность проекта. Причинами, стимулирующими решение автоматизации, могут быть:

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

Определение целей проекта внедрения ИС, включая цели построения ИС, критерии качества. Качественные характеристики достижения целей, качество управления и т.д.
Цели проекта внедрения - построение ИС заданного качества, за планируемое время и средства. На этапе ППО определяются цели внедрения ИС. В силу того, что задача построения ИС является многокритериальной задачей, достичь одновременно всех целей с наилучшими показателями вряд ли возможно. Скажем, объем информации и скорость ее обработки обратно пропорциональны. Если система обрабатывает единицу информации за единицу времени, нельзя поставить целью - обработать 1000 единиц информации за ту же единицу времени. Следовательно, цели внедрения необходимо строить в виде иерархического дерева - от более важных к менее важным (в ущерб качества которых будет достигаться более высокое качество целей верхнего уровня). Для однозначного определения уровня достижения целей определяются качественные характеристики целей. Те, которые можно однозначно измерить по определенной шкале. Например, хорошая цель - привить процессную культуру персоналу, может быть сформулирована как прогноз. Как цель ее вряд ли стоит рассматривать ввиду сложности измерения динамики того самого понимания. Или - оптимизация процессов. Оптимизированы процессы или нет - можно сказать, только измерив, конкретные параметры, например, время выполнения торговой транзакции. Была такая, стала другая. Если декларируется цель, не поддающаяся измерению, ее не следует включать в дерево целей. Все это личное мнение, даже не продуманное как следует. Требует обсуждения. Качественными характеристиками могут быть, например:

булево да - нет (наличие или отсутствие какой-либо функции, параметра, свойства);
измеряемые параметры и способы измерения (измеряемые величины: время исполнения, количество объектов, объем памяти и т.п.);
оценочные параметры и способы оценки (параметры, которые сложно или невозможно измерить прямым способом оцениваются по какой-либо качественной шкале: балльная система, абсолютная процентная, также оговариваются способы оценки, например, мажоритарная, усредненная и т.д.).
Пожалуй, кроме булевой шкалы, задать качественную характеристику цели одним показателем – для большинства целей, по меньшей мере, авантюризм. Следовательно, в дереве целей, качественные характеристики следует задавать в виде диапазонов (рамок) от и до. От недопустимых с точки зрения потребности, до недопустимых с точки зрения времени и/или стоимости реализации. При таком подходе появляется возможность оптимизации поставленных целей путем подбора параметров внутри рамок.

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

Определить финансовые ограничения, в отличие от недостатка знаний, относительно просто.

Тогда - это будут ограничения финансовых ресурсов, людских, временных, материальных, технологических?

Ограничения:

финансовых ресурсов - бюджет проекта;
людских ресурсов - персонал, задействованный в проекте, с учетом планируемого коэффициента трудового участия;
временных ресурсов - время, отведенное на выполнение проекта в целом и его этапов в частности;
материальных ресурсов - материально - техническая база, используемая до начала проекта;
технологических ресурсов - ПО, технологии, методологии, используемые до начала проекта.
Сбор информации и прогнозирование.
Первичные документы.
Собираются формы первичных документов. Разрабатывается кодификатор. Составляется каталог первичных документов, закодированный в соответствии с принятым кодификатором документов. Коды документов указываются в соответствии с “Журналом унифицированных форм первичных документов”, если они соответствуют журналу. Если не соответствуют, присваивается внутренний код. В последующем, необходимо стремиться к использованию всех форм документов, соответствующих унифицированным формам, за исключением необходимых внутренних форм. Таким образом, собирается информация для выработки стандарта на первичные документы.

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

Формат опросного листа (1-я итерация):

Процесс (отдел) Владе-лец (ответ-ствен-ное лицо) Опера-ция (функ-ция) Передана от (роль) Обра-баты-вает (роль) Переда-ется кому (роль) Сопут-ствующий документ (ссылка на каталог первичных форм) Содер-жание опера-ции (фун-кции)
1
2
3
4
5
6
7
8


Для процессов заполнение формы начинается с п.п. 4-8. После обработки информации, на этапе моделирования, операции соотносятся с процессами. За процессами закрепляются владельцы.

После сбора информации, на ее основе, составляется прогноз о возможности достижения поставленных целей по срокам и объемам финансирования.

Характеристика объекта (паспорт предприятия).
На основании собранных данных составляется краткая характеристика предприятия как объекта управления. К этим характеристикам могут относиться:

отраслевая принадлежность;
виды деятельности;
величина предприятия:
количество работающих;
организационная структура в общем виде;
филиалы (количество, удаленность);
годовой оборот в денежном выражении;
годовой оборот в натуральном выражении (например, объем грузоперевозок);
техническое оснащение;
…
стратегия развития;
{Е. Н. С. Все эти моменты отлично расписаны в анкете Аквариуса – подробный опросник поможет собрать необходимую информацию. Е. Н. С. }

Построение бизнес-модели предприятия (модели управления) верхнего уровня.
Учитывая то, что, с одной стороны, реализация проектов внедрения ERP-систем растягивается на годы, с другой то, что в ERP-системе заложена функциональность, перекрывающая потребности большинства предприятий, заложена определенная бизнес-логика, следует принять к рассмотрению методологию быстрого внедрения ERP-системы. Такая методология существует для большинства известных систем (Fast forward для Oracle, Diamand для Axapta и т.п.). Следует внимательно рассматривать возможности методологий такого типа, отсекая маркетинговую “шелуху”. В целом, подход представляется разумным. Процесс изучения логики системы, построения модели с учетом этой логики и настройка системы по времени должен быть значительно короче, чем изобретение и детальная прорисовка модели управления предприятием, а затем реализация этой модели в системе. На этом этапе необходимо прорисовать модель на верхнем уровне, не углубляясь.

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

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

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

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

ИЛИ Уточнение характеристик предприятия (8).
ИЛИ Пересмотр модели управления (9).
ИЛИ Пересмотр границ автоматизации (10).
ИЛИ Переопределение этапов автоматизации (11).
ИЛИ Пересмотр постановки задачи (12).
ИЛИ Пересмотр модели управления бизнесом, соответствующей первому этапу (13).
ИЛИ Принятие предварительного решения (15).
Исполнение в пилотном варианте.
Этап реализации пилотного варианта.

Оценка результата по утвержденным критериям.
ИЛИ Пересмотр модели управления (9).
ИЛИ Пересмотр границ автоматизации (10).
ИЛИ Переопределение этапов автоматизации (11).
ИЛИ Пересмотр постановки задачи (12).
ИЛИ Пересмотр модели управления бизнесом, соответствующей первому этапу (13).
ИЛИ Принятие этапа (17).
Исполнение. Внедрение (10).
Таким образом, видно, что процесс замкнут, имеет итерационный характер. Поэтапная реализация дает практические результаты в процессе внедрения. Реализация этапов может быть организована в параллельном режиме. В процессе реализации уточняется план и регламент работ с точки зрения эффективности (соотношения времени, стоимости, качества).

[Елена Сысовская]

Планирование и управление качеством ИС.

Адрес проекта IT2B, на котором опубликован материал документа: it2b.h1.ru

ред. 1.

Сысовская Елена.

Оглавление
1 Последовательность действий *

2 Управление качеством проекта. *

1.1 Построить систему требований к качеству проекта с учетом потребностей организации и возможностей выбранной конфигурации системы. *

Построить систему требований с учетом потребностей организации. *

С учетом возможностей системы. *

1.2 Определиться с конфигурацией и стоимостью проекта. Построить систему требований к ПП для конкретного проекта – с учетом возможностей выбранной конфигурации планируемой системы. *

1.3 Подготовить экономическое обоснование проекта. *

1.4 Создать систему ключевых показателей. *

1.5 Построить модель ИС. *

Зафиксировать порядок и правила исполнения рабочих процедур. *

Создать модель работы ИС. *

Выработать стандарты ИС. *

Согласовать состав справочников и классификаторов. *

Утвердить новую схему бизнес - процессов. *

Необходимо определять приоритеты. *


Описание как последовательности действий:

Цели внедрения ИС, построить их иерархию. Решение наших задач
Минимальная стоимость

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

Управление качеством проекта.

Построить систему требований к качеству проекта с учетом потребностей организации и возможностей выбранной конфигурации системы.

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

Построить систему требований с учетом потребностей организации.

Определить вопросы, на которые необходимо получать ответы в процессе работы ИС.
Например:

Какова структура затрат? Структура доходов?
Какие продукты и сегменты должны быть целевыми (удовлетворение клиента)?
За счет чего можно поднять доход и прибыльность по продуктам и потребителям?
Какова зона ключевой компетенции компании?
Эффективно ли использовались ресурсы для достижения поставленной цели и увеличения прибыли?
{В.Н. Я думаю, что все эти вопросы относятся в первую очередь к управлению бизнесом (принятию бизнес-решений), а не к ИС. Да, ИС предназначена для помощи в принятии бизнес-решений. Но давать ответы в терминах, прозвучавших в пунктах выше, система вряд ли сможет. Поэтому надо сразу строить “дерево” вопросов, вплоть до тех, ответы на которые будет давать ИС. Иначе мы опять попадем в неопределенное состояние. Система дает то-то и то-то, а отвечает ли все, что она дает на те вопросы, которые ставит бизнес? Я думаю, что в результате построения такого дерева мы придем к некой аналитике на уровне структур объектов (контрагенты, тмц и т.д.). А все остальные ответы на вопросы, находящиеся на “дереве” выше мы получим путем запросов. Для этого нужно “всего лишь” наличие всех аналитических признаков (т.е. должно продумать какая аналитическая информация потребуется для ответов на “дерево” вопросов) и хорошей системы запросов. Скорее всего, аналитика будет избыточной и сможет отвечать на вопросы в различных разрезах, даже не предусмотренных изначально. Лишь бы не придумали вопросов другого порядка. В.Н.}

Требования к проекту внедрения ИС и ожидаемые результаты. Должны быть предельно конкретны. Детализировать необходимо до достаточного уровня, не более, иначе это займет очень много времени.
Например:


Формулировка стратегии увеличения прибыльности и стратегических целей.
Например:

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



С учетом возможностей системы.

Функциональность.
Список процессов, которые будут реализованы в ИС.
Список возможностей, которые связаны со спецификой деятельности организации и традиционно вызывают проблемы при реализации. (фискальный учет по нескольким юридическим лицам, розничная торговля ( с применением торгового оборудования), взаимозачетные схемы, работа с удаленными подразделениями, совмещение с используемым ПО).
Список “узких мест” - требования к системе по способности выполнения процедур, которые требовали большого количества ручных операций или выполняли слишком медленно.
Требования соответствия модели ИС и бизнес модели (сохранение времени, места, периодичности, длительности, владельца исполнения реального процесса).
Требованиями к безопасности.
Акцент необходимо сделать на эффективную реализацию функций управления предприятием (поддержка принятия решений).
На основании стратегического плана развития предприятия сформулировать требования к гибкости ИС и способности обеспечивать будущие потребности на период работы системы. Например, если через год планируется интеграция с поставщиками по технологии B2B, или изменения масштаба организации (документооборота, количества сотрудников, подразделений, изменения структуры бизнеса) и в результате запланировано изменение бюджета, то в ИС должна быть заложена соответствующая возможность изначально, т.к. год – недостаточный срок и для внедрения ИС и для модификации.
Технологичность.
Количество транзакций.
Количество пользователей.
Удаленные пользователи.
Скорость выполнения задач.
Совместимость с программными и техническими средствами (Интернет).
Физическая структура данных.
Экономичность.
Ресурсоемкость. Время, деньги, персонал.
Экономический эффект.
Определиться с конфигурацией и стоимостью проекта. Построить систему требований к ПП для конкретного проекта – с учетом возможностей выбранной конфигурации планируемой системы.

Требования к информационной системе, сформулированные на основании требований бизнеса корректируются с учетом возможностей выбранной информационной системы.

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

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

Подготовить экономическое обоснование проекта.

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

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

Оценка экономического эффекта.
Надо отличать такую “простую” оценку от оценки экономического эффекта внедрения новой ИС, которая также состоит из двух частей – расходной и доходной. Расходная часть строится на основании оценки потерянной от вложения в ИС средств прибыли и учета величины вложенных средств, а доходная – от экономической прибыли, полученной в результате внедрения ИС К сожалению, проверенных методик расчета экономической прибыли от внедрения ИС я не знаю. Эти методики должны учитывать эффективность новой стратегии предприятия, действующего в меняющихся условиях в будущем, на достаточно длительный срок. Можно оценить, сколько процентов составляет стоимость проекта внедрения от месячного оборота фирмы (в перерасчете на всю длину проекта). Это необходимо для оценки приемлемости всего проекта. Может ли предприятие позволить себе такую цену ИС – необходимо решить до начала проекта внедрения. Есть мнение, что норма – 1-2%, но доказательств в подтверждении таких предположений нет.

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

Создать систему показателей качества.

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

Построить согласованные модели ИС и модель БП.

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

Зафиксировать порядок и правила исполнения рабочих процедур.

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

Создать модель работы ИС.

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

Выработать стандарты ИС.

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

Согласовать состав справочников и классификаторов.

Утвердить новую схему бизнес - процессов.

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

Необходимо определять приоритеты.

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