Реферат: Реорганизация бизнес-процессов при изменении информационной системы в крупной организации

Реорганизация бизнес - процессов

при изменении информационной системы

в крупной организации.

Содержание:

1. Концепция информационной системы и требования которые могут к ней предъявляться

2. Типы изменений информационной системы

3. Принципы планирования проекта по изменению информационной системы

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

1. Концепция информационной системы и требования которые могут к ней предъявляться

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

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

· процесс приема заказов

· учет складского инвентаря

· учет транспортировок продукции

· процесс закупок продукции

· процесс таможенной очистки продукции

· бухгалтерское отражение всех указанных процессов

· учет счетов к получению

· учет счетов к выплате

· учет затрат и т.д.

__________________

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

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

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

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

Типы изменений информационной системы

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

вид изменения информационной системы

причина изменения информационной системы

область изменения информационной системы

масштаб вовлечения ресурсов.

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

Вид изменения информационной системы

Здесь имеется в виду, насколько качественно сильным и радикальным является изменение. Можно условно выделить следующие типы изменений:

Установка системы с нуля при отсутствии какой-нибудь предыдущей системы (установка с нуля ).

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

Расширение функциональных возможностей существующей системы (расширение функций ).

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

Отчуждение части функциональных возможностей существующей системы (отчуждение функций ).

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

Установка новой информационной системы при сохранении части функциональности старой системы (пристройка системы ).

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

Установка новой информационной системы при полном отчуждении старой системы (полная смена системы ).

Это один из самых сложных проектов, потому что при его реализации следует учитывать сразу весь комплекс факторов:

- изучение процессов организации для проведения анализа при тестировании новой системы;

- изучение возможностей новой системы по сравнению со старой применительно к процессам организации;

- моделирование тестовых ситуаций;

- тестирование новой системы как в предварительном режиме, так и в режиме работы с реальными данными, вплоть до двойного ввода данных - в новую и старую систему одновременно;

- принятие решений относительно изменений в процессах, которые можно осуществить при смене системы;

- подготовка менеджмента и персонала к проведению изменений в процессах;

- обучение персонала работе с новой системой;

- планирование перехода со старой системы на новую при сохранении правильности данных и их учета;

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

Установка системы, которая выполняет роль интерфейса между двумя существующими, но не совместимыми ранее системами (установка интерфейса ).

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

Причина изменения информационной системы

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

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

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

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

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

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

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

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

Область изменения информационной системы

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

логистика

бухгалтерский учет

финансовый анализ

учет кадров

маркетинг

продажи/ покупатели

отчетность

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

Масштаб вовлечения ресурсов.

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

люди

время

набор функций, которые предстоит поменять/ внедрить

стоимость (бюджет).

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

насколько проект является сложным с технической точки зрения,

насколько сложным является сам процесс изменения информационной системы,

насколько интенсивными или даже агрессивными являются планы по реализации проекта,

насколько дорогостоящим является проект,

насколько в целом проект важен для организации и т.д.

Если рассматривать масштаб вовлечения и использования ресурсов, то здесь ключевым будет определение того, насколько велик он для организации. Учитывая, что невозможно указать общие характеристики и критерии того, какое вовлечение ресурсов в абсолютном выражении является большим, а какое нет, можно предложить использовать набор субъективных факторов, которые могут дать основу для определения величины масштаба использования ресурсов. К таким факторам можно отнести следующие:

доля сотрудников компании, принимающих непосредственное участие в проекте,

доля сотрудников компании, в той или иной степени вовлеченных в проект,

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

качественное содержание функциональности, ее сложность и охват бизнес процессов,

доля бюджета, отведенного на реализацию проекта,

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

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

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

большой,

средний и

маленький.

Позиционирование типа изменения информационной системы:

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

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

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

рис. 2.1. Матрица для позиционирования типа изменения информационной системы.

Принципы планирования проекта по изменению информационной системы

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

Начальное планирование проекта.

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

Как вообще принимается решение о проведении изменений в информационной системе? Причины изменения информационной системы описаны в предыдущем разделе:

технические характеристики системы

область деятельности организации

функциональность системы

моральное устаревание системы

политика организации относительно стандартизации процессов

интеграция различных областей деятельности организации

престижность использования новой системы

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

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

Рассмотрим основные составляющие, которые следует включить в начальный план проекта:

Описание объекта изменения (что необходимо изменить - систему, часть ее функциональности и т.д.);

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

Основные стадии проекта (см. ниже);

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

Список участников проекта, их основных обязанностей и ролей (менеджер проекта, топ менеджмент, ресурсы, участники и т.д.);

Бюджет проекта;

Что не войдет в проект (это необходимо для внесения ясности в ожидания менеджеров рабочих групп относительно возможностей системы);

Какие функциональные возможности системы нужно изучить в дальнейшем для потенциальной установки в дальнейшем (список);

Риски (какие факторы могут помешать реализации проекта в полном объеме, в поставленные сроки с установленным бюджетом);

Критерии успешного выполнения проекта

Список необходимых условий, от которых зависит успешная реализация проекта.

Планирование в процессе осуществления проекта.

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

Рис. 3.1. Планирование проекта по изменению информационной системы.

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

Рис. 3.2. “Сроки проекта - содержание проекта”

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

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

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

Стадии проекта по изменению информационной системы.

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

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

Описание бизнес процессов

Тренинги по новой системе (при необходимости)

Тестирование функциональности системы

Необходимые доработки

Обучение пользователей функциональности системы

Тестирование системы пользователями

Ввод реальных данных

Переход на новую систему

Рассмотрим более детально каждую стадию.

Описание бизнес процессов.

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

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

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

Тренинги по новой системе (при необходимости).

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

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

Тестирование функциональности системы.

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

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

Необходимые доработки.

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

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

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

Обучение пользователей функциональности системы.

После того, как функциональность системы протестирована, необходимые доработки сделаны, наступает стадия, которая является прелюдией к шлифовке системы. Участники проекта начинают обучать пользователей работе с системой. Это необходимо не только для того, чтобы они смогли качественно протестировать систему и выдать свои рекомендации, но также и для того, чтобы они привыкли к системе и натренировались для дальнейшего эффективного включения в работу с новой системой (так называемый “training on the job”), а потенциально возможный негативный настрой растворился в изучении возможностей системы и предварительной работе с ней.

Тестирование системы пользователями.

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

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

разработка набора сценариев тестов для пользователей:

тесты, проверяющие функциональность системы;

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

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

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

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

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

Ввод реальных данных.

После того, как все необходимые детали по работе системы согласованы с пользователями, система признается готовой к установке, а топ менеджмент принимает окончательное решение о внедрении (так называемое “go-no-go solution”), начинается сам переход с одной системы на другую.

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

Ввод данных (все системные настройки должны быть уже введены в систему на стадии тестирования системы пользователями) начинается с ввода так называемых мастер - данных:

заказчики, их адреса, контактные лица и т.д.;

список продуктов с необходимыми характеристиками, такими, как количество штук в коробке, размеры, вес, коды и т.д.;

цены и скидки - как на продукты (закупочные и продажные), так и на другие услуги (перевозки, консультации, денежные переводы и т.д.);

склады, их адреса, контактные лица и т.д.;

поставщики, их адреса, контактные лица и т.д.;

другие партнеры (перевозчики, консультанты, банки и т.д.);

транспорт, характеристики машин (объем, тип, номера и т.д.);

другое.

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

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

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

Переход на новую систему.

Переход на новую систему означает прекращение ввода данных в старую систему и начало (продолжение, если переход был плавным, как это было описано выше) ввода данных только в новую систему.

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

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

Структура команды участников проекта и взаимоотношения между ними.

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

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

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

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

Взгляд на организацию в период реализации проекта.

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

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

В проекте принимают участие следующие группы людей (рис 4.1.), роли которых будут описаны чуть ниже:

Топ менеджмент

Менеджер проекта

Участники проекта

Ключевые ресурсы

Менеджеры ключевых ресурсов

Пользователи

Менеджеры пользователей

Рис 4.1. Группы людей, принимающих участие в проекте.

Рассмотрим более детально каждую из групп.

Менеджер проекта и участники проекта несут основную нагрузку по анализу информации и преобразованию ее в требуемый результат. В проекте по изменению информационной системы данные люди анализируют возможности осуществления бизнес - процессов в новой системе. Во многом их деятельность заключается в моделировании процессов в системе (которая в данном понимании является некой базой, по которой строятся процессы). Однако сам дизайн новой системы задается требованиями, которые предъявляются к системе со стороны всех заинтересованных сотрудников. Здесь автор сознательно не расписывает группы людей, которые могут повлиять на требования к системе, потому что возможность повлиять на требования к системе должна быть у каждого сотрудника, потому что нередко даже случайные идеи, высказанные человеком, который не имеет прямого отношения к процессу, могут развиться в значительные изменения, которые могут повлечь за собой улучшения процессов или минимизацию ресурсов, задействованных в процессах организации (это может произойти от того, что люди, мышление которых не связано устоявшимися схемами в какой-то области, гораздо легче могут выйти за границы, диктующиеся данными схемами - так называемый эффект “thinking out of the box”).

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

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

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

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

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

сокращение количества своих сотрудников или требуемого времени на работу с системой и с процессами,

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

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

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

дополнительные возможности отчетности для оперативной или аналитической деятельности,

и т.д.

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

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

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

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

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

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

Приложение 1.

Прием заказа .

Прием заказа:

Заказ принимается по:

Электронной почте

Факсу

Телефону

Типы заказов: 22 паллетные, 33 паллетные а/м, ж/д вагоны или контейнеры

Типы транспортировки:

Доставка транспортом компании

Самовывоз

При необходимости корректировки заказа - оператор звонит заказчику и согласовывает изменения в заказе

Ввод заказа в систему:

Заказ (заголовок):

Покупатель

Номер заказа

Требуемая дата доставки

Дата обработки заказа

Дата действия прейскуранта

Заказ (строчки):

Код товара

Кол-во коробок

Единица измерения (коробка)

Заказ трансформируется в Поставку:

Поставка (заголовок):

Получатель

№ поставки

Вес поставки

Дата отгрузки (предлагается системой)

Поставка (строчки):

Код товара

Кол-во коробок

Единица измерения (коробка)

Кредитный контроль (разрешение/ блокировка/ изменение заказа) и проверка на наличие товара (товар есть/ товара нет ® изменение заказа) осуществляются системой

Сравнение заказа и измененного заказа: генерирование отчета об отказах

Окончательное согласование заказа при необходимости:

Изменения согласовываются по телефону

Оператор подтверждает заказ

Заказчику сообщается номер заказа и сумма к оплате

Транспортная группа согласовывает доставку товара

Отчет о заказах к отгрузке

Заказ на перевозку

Ввод транспортных данных в систему

Распечатка заказа

Формирование подборки заказа в системе для склада:

Заголовок:

Получатель

№ поставки

Дата отгрузки

Общий вес

Строчки:

Склад

Камера

Товар

Количество

Единица измерения (коробки)

Подобранное количество

Единица измерения (коробки)

Сохранение изменений

Разноска (пост)

Оформление и распечатка счета

Генерирование отчета об открытых заказах

Генерирование отчета о разрешенных заказах

Приложение 2. Выдержка из начального плана проекта.

Project Organisation

Project Sponsor

Person A F&A Manager Russia

Person B Logistics Manager Russia

Other Board Members

Person C IT Manager Russia

Steering Team

Person D

Person E

Person F

Person G

Project Manager

Person H IT Project Manager

Project Team

IT: Person I IT Analyst

Person J IT Analyst

F&A: Person K F&A Clerk

Logistics: Person L Logistics Project Manager

Logistics: Person M Logistics Project Assistant

Warehouse: Person N Warehouse Manager

Local Resources

Logistics: Person O Logistics Development Manager

Person P OSB Manager

Person Q Moscow Distribution Manager

Person R Deployment Manager

Person S Moscow WH&Transport Manager

Person T Supply Planning Manager

Person U Customs Manager

Warehouses: Person V Warehouse “A”

Person W Warehouse “B”

Person X Warehouse “C”

F&A: Person Y Accounting Manager

Person Z GL Supervisor

Person AA Banking Manager

Person AB Profit Forecaster

IT: Person AC Corporate Support Services Manager (I&TS)

Person AD Warehouse Systems Engineer

Person AE Finance Systems Analyst

Person AF Finance Systems Analyst

Person AG System Administrator

External Resources

SAP R/3 RSG

EMEA Implementation Support Team

SAP Consult C.I.S.

Stakeholders

F&A analysis

Sales Department

Marketing Department

Platinum RSG

Key Roles and Responsibilities:

Project Board:

Allocate and make funds and resources available;

Communicate to Project Manager all environmental and business changes that impact the project;

Confirm business and technical requirements;

Confirm assumptions;

Resolve key issues as identified;

Review and approve overall project plan and schedules;

Manage effort against priorities;

Review progress and communicate to business partners and appropriate MSD people;

Review and authorize project exception plans, if applicable;

Meets monthly (or as issues arise) to review project progress.

Project Manager:

Develop and manage overall critical path schedule for the effort;

Coordinate the effort of people and develop roles/expectations for people working on the team;

Identify and obtain required resources;

Insure proper approvals for business and technical solutions;

Resolve or escalate issues to Project Board and/or Steering Team as needed;

Communicate the impact on the Stakeholders;

Interfaces with other key MS projects impacting SAP R/3 project and ensure compatibility;

Host and work with RSG resources;

Meets monthly (or as issues arise) with Project Board to report project progress;

Meet with team be-weekly (or as issues arise) and prepare meeting notes;

Be trained on FI, CO, SD and MM modules.

Business Team Members:

Formalize business requirements of their organizations;

Together with PM and MS TMs develop compromise business solutions in case of conflicting business requirements;

Ensure the implementation of changes in business process is properly communicated to their organizations;

Coordinate business testing and Quality Assurance in their organizations;

Recommend resources from their organizations for each stage;

Escalate issues to Project Manager as needed;

Be trained on FI, CO, SD and MM modules.

MS Team Members:

By help of Business TMs map business processes into system in a way that ensures feasibility of technical realization;

Provide technical solutions;

Ensure compliance with global standards;

Initiate the development/approval of alternative business solution if the initial one is not technically feasible;

Escalate issues to Project Manager as needed;

Be trained on FI, CO, SD and MM modules.

Key Business Resources:

Present business requirements for their organization to the project;

Liaise and reconcile business requirements with Key Business Resources from other organizations;

Assist in the collective prioritization of business requirements;

Review the major deliverables of the project;

Communicate plans, progress, status, expectations, etc. for the project back to their organizations;

Inform PM about their unavailability.

Key MS Resources:

Will be involved in order to ensure smooth transition from Platinum to SAP and engaged in some specific tasks