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

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



НазваниеРеорганизация бизнес-процессов при изменении информационной системы в крупной организации
Дата конвертации30.07.2012
Размер340.76 Kb.
ТипРеферат
Реорганизация бизнес-процессов при изменении информационной системы в крупной организации


Реорганизация бизнес - процессов при изменении информационной системы в крупной организации. Содержание:1. Концепция информационной системы и требования которые могут к ней предъявляться2. Типы изменений информационной системы3. Принципы планирования проекта по изменению информационной системы4. Принципы формирования и работы команды, отвечающей за изменение информационной системы, подбор ее участников и взаимоотношения с организацией1. Концепция информационной системы и требования которые могут к ней предъявлятьсяВ настоящее время понятие информационной системы настолько размыто, что подинформационной системой может быть определено любое понятие от компьютернойпрограммы, помогающей автоматизировать какой-то процесс, до сложивщегосянабора правил и процедур, регламентирующих действия сотрудников компании поорганизации процессов создания и использования информации в нужном длякомпании виде.Поэтому не ставя перед собой задачу рассмотреть все возможные определениядля информационной системы, автор предложил бы1 понимать под информационнойсистемой интегрированную базу данных, позволяющую благодаря своейфункциональности обрабатывать широкий спектр бизнес процессов, в которыймогут входить следующие (поскольку данная работа связана с участием авторав конкретном проекте по интеграции новой информационной системы в крупнойкомпании, определенные области деятельности организации могли не войти вданный список, как например кадровый учет, некоторые финансовые,бухгалтерские и логистические аспекты, маркетинг и т.д.): . процесс приема заказов . учет складского инвентаря . учет транспортировок продукции . процесс закупок продукции . процесс таможенной очистки продукции . бухгалтерское отражение всех указанных процессов . учет счетов к получению . учет счетов к выплате . учет затрат и т.д.__________________1Поскольку выбор данной темы был обусловлен участием автора в проекте, вомногом отражающем тенденции по изменению информационных систем в крупныхкомпаниях, автор счел возможным рассматривать процесс перехода крупныхкомпаний к новой интегрированной базе данных с широкой функциональностью вомногом типичным, а следовательно и саму базу данных (постепеннозавоевывающую рынок «крупных» информационных систем) типичной и наиболееподходящей под определение информационной системы.Что касается функциональности информационной системы, то признаком«системности» автор предложил бы считать степень разработанности даннойфункциональности. Чем больше областей деятельности организации охватываетданная конкретная база данных, и чем больше функциональных возможностей поучету нестандартных «жизненных ситуаций» эта база данных предоставляет, темближе ее можно отнести к информационной системе. Естественно информационнаясистема должна быть способна обрабатывать достаточные объемы информации(определяемые размером бизнеса конкретной организации) за относительнокороткое время.
Под «интегрированностью» информационной системы можно понимать степеньсвязанности всех процессов организации, которые нашли отражение в системе,в единое целое. Типичным примером интегрированной системы может бытьсистема, которая позволяет учитывать и логистические, и бухгалтерскиепроцессы. Например, при оформлении в системе заказа, который делаетзаказчик, в системе возникает соответствующая бухгалтерская проводка,увеличиваются счета к получению и уменьшается количество товара на складе,которое имеет статус свободного использования.Предложив понимать под информационной системой описанное выше иограничиваясь перечислением факторов, свойственных информационной системе,автор дал бы неполное представление о ней. Одной из важнейших компонент,непосредственно связанных с информационными системами, являются люди,использующие систему в своих целях, и процессы, регламентирующиедеятельность сотрудников по использованию системы. Организация данныхпроцессов и обучение сотрудников работе с системой являются ключевойпредпосылкой успешного функционирования системы и будут описаны ниже приописании изменения информационной системы.2. Типы изменений информационной системыИзменения информационной системы можно классифицировать в зависимости отнескольких факторов. Под такими факторами автор предложил бы пониматьследующие:1. вид изменения информационной системы2. причина изменения информационной системы3. область изменения информационной системы4. масштаб вовлечения ресурсов.Опишем каждый из факторов более подробно, сделав оговорку, что внезависимости от фактора или типа изменения каждый проект, относящийся кизменению информационной системы, имеет свои настолько уникальные черты,что вряд ли возможно найти два абсолютно идентичных проекта в этой области.Это в первую очередь можно объяснить спецификой и уникальностью внутреннейорганизации бизнес процессов в каждой компании, а также видом еедеятельности.1. Вид изменения информационной системыЗдесь имеется в виду, насколько качественно сильным и радикальным являетсяизменение. Можно условно выделить следующие типы изменений:. Установка системы с нуля при отсутствии какой-нибудь предыдущей системы (установка с нуля).Здесь существенным моментом является то, что бизнес процессы не были автоматизированы, а внедрение системного подхода к ведению бизнеса требует автоматизации. В принципе этот тип целесообразно применять тогда, когда объемы бизнеса таковы, что уже становится трудно управлять ими и анализировать их на исключительной основе (то есть каждое событие в отдельности). Требуется какой-то механизм, позволяющий стандартизировать показатели, по которым происходит анализ эффективности деятельности организации.. Расширение функциональных возможностей существующей системы (расширение функций).Такое изменение возможно в двух случаях. В первом случае те процессы, которые попадают под расширенные функциональные возможности системы, начинают требовать системного стандартного подхода, как описано в предыдущем пункте. Второй случай происходит тогда, когда те процессы, которые не отслеживались в системе, ранее отслеживались в другой системе. Это происходит, если другая система становится неэффективной, а та система, у которой расширяются функциональные возможности, позволяет отслеживать данные процессы эффективно. К особенностям этого типа изменений относится необходимость тщательного изучения возможностей дополнительной функциональности системы и ее адаптация к процессам в организации, где особенно важно учесть подготовку персонала к работе с системой.. Отчуждение части функциональных возможностей существующей системы (отчуждение функций).Такого типа изменения возможны в случае изменения деятельности организации (в частности, если какой-то из процессов, существовавших ранее и игравших важную роль, перестает быть актуальным). Например, при постройке завода прекращается импорт продукции, что приводит к тому, что процесс растаможки исчезает, и его эффективность не отслеживается, что в свою очередь приводит к отчуждению таможенного модуля информационной системы.. Установка новой информационной системы при сохранении части функциональности старой системы (пристройка системы).Здесь возможен вариант, когда новая система существует в качестве надстройки к старой и выполняет часть функций, которые раньше выполняла старая система или выполняет часть новых функций. Здесь, как и в предыдущем разделе, следует особое внимание обратить изучению возможностей новой системы, обучению персонала, а также организации коммуникации данных между двумя системами.. Установка новой информационной системы при полном отчуждении старой системы (полная смена системы).Это один из самых сложных проектов, потому что при его реализации следует учитывать сразу весь комплекс факторов: - изучение процессов организации для проведения анализа при тестировании новой системы; - изучение возможностей новой системы по сравнению со старой применительно к процессам организации; - моделирование тестовых ситуаций; - тестирование новой системы как в предварительном режиме, так и в режиме работы с реальными данными, вплоть до двойного ввода данных - в новую и старую систему одновременно; - принятие решений относительно изменений в процессах, которые можно осуществить при смене системы; - подготовка менеджмента и персонала к проведению изменений в процессах; - обучение персонала работе с новой системой; - планирование перехода со старой системы на новую при сохранении правильности данных и их учета; - поддержка нормального функционирования новой системы в ближайшее время после перехода и в дальнейшем.. Установка системы, которая выполняет роль интерфейса между двумя существующими, но не совместимыми ранее системами (установка интерфейса).Для такого типа изменений характерна необходимость проведения тренингов для персонала по разъяснению основных изменений при работе с системами относительно новых возможностей, которые появляются при создании интерфейса, а также тщательное планирование технических разработок интерфейса.2. Причина изменения информационной системыПричина изменения информационной системы позволяет определить, почемупроизошла смена системы в организации. В качестве примеров можно привестиряд наиболее распространенных причин, по которым происходят изменения винформационной системе:. технические характеристики системы (быстродействие, способность обрабатывать определенные объемы информации, совместимость с существующими системами, удобность использования). Здесь ключевую роль играет критичность технических способностей системы - если старая система не в состоянии обрабатывать вводимую в нее информацию с нужной скоростью, то тогда данная причина является одной из основных, из-за которых происходит изменение или смена информационной системы.. область деятельности организации (появление новых процессов или исчезновение старых). Изменение деятельности приводит к изменению процессов, в процессах требует изменения в системе.. функциональность системы (набор функций, которые может поддерживать система - от обработки информации до конкретных процессов, которые можно отслеживать в системе). Напрямую связана с областью деятельности организации и размером бизнеса. При изменении деятельности организации происходит изменение функциональности системы, при изменении размера бизнеса может возникнуть или отпасть необходимость систематической и электронной регистрации информации (например, если фирма производит всего несколько отгрузок в день, то не надо хранить статистики по тому, как качественно прибывает транспорт к заказчику - во время/ не во время, если же фирма отгружает по 40-50 или более грузовиков к заказчикам, то в этом случае просто необходимо вести статистику по количеству опозданий и работать по улучшению показателей, иначе качество сервиса может начать постепенно ухудшаться, что потенциально может привести к потере покупателей).. моральное устаревание системы (старая версия меняется на новую). Достаточно распространенная ситуация; часто бывает так, что новая версия информационной системы не только удобней в использовании, но и предоставляет более совершенные технические характеристики и более широкую функциональность.. политика организации относительно стандартизации процессов в разных отделениях организации (подведение всех процессов под один стандарт и как следствие установка стандартной информационной системы). Данная причина характерна для компаний с большим количеством филиалов. Если компания стремится к стандартизации бизнес процессов (что имеет ряд существенных преимуществ, таких как экономия на использовании единого формата процессов и обработки данных, внедрение передового опыта, экономия при организации бизнес процессов в новых филиалах, широкие возможности для развития и перемещения сотрудников между филиалами и т.д.), то для нее кроме организации единого стандарта реализации бизнес процессов еще и необходимо установить единую систему, которая будет являться механизмом по реализации стандартного подхода, а также инструментом интеграции данных для анализа.. интеграция различных областей деятельности организации (пример - интеграция в одну системы бухгалтерии и логистики). Данная причина связана с возможностью экономии на затратах ресурсов по ведению данных при объединении разных процессов, регистрируемых в организации на системном уровне.. престижность использования новой системы. Может являться конкурентным преимуществом для организаций, работающих в сфере информационных технологий или услуг (особенно в сфере услуг по предоставлению информации).3. Область изменения информационной системыПод областью изменения информационной системы предлагается понимать тусферу информационной системы, которая относится к определенной системебизнес процессов в деятельности организации. Основываясь на опыте,полученном автором во время работы, можно определить следующий базовыйнабор сфер информационной системы: . логистика . бухгалтерский учет . финансовый анализ . учет кадров . маркетинг . продажи/ покупатели . отчетностьВряд ли есть смысл описывать составляющие каждого элемента предложенногобазового набора, потому что во-первых, каждая организация обладает своейуникальной спецификой, а следовательно далеко не каждая организацияидеально подпадала бы под детально расписанный базовый набор, а во-вторых,описание потребовало бы слишком много внимания, что изменило бы внутреннююлогику данной работы и ее цель - описание изменений, которые могутвозникнуть в организации с изменением информационной системы.4. Масштаб вовлечения ресурсов.Изменение информационной системы можно также охарактеризовать с точкизрения тех ресурсов, которые вовлечены в процесс изменения информационнойсистемы и соотношения вовлеченности этих ресурсов. Под ресурсами авторпредложил бы понимать следующие неотъемлемые составляющие любого проекта, втом числе и проекта по изменению информационной системы: . люди . время . набор функций, которые предстоит поменять/ внедрить . стоимость (бюджет).Важную роль здесь играет соотношение вовлеченности ресурсов в проект. Этоявляется своего рода качественным показателем стиля проведения изменений вкомпании, а также может позволить оценить эффективность менеджмента,применимого к проекту - естественно при детальном изучении данногоконкретного проекта. Если управление проектом организовано грамотно идетально продумано, соотношение вовлеченности ресурсов может датьпредставление о том, . насколько проект является сложным с технической точки зрения, . насколько сложным является сам процесс изменения информационной системы, . насколько интенсивными или даже агрессивными являются планы по реализации проекта,. насколько дорогостоящим является проект,. насколько в целом проект важен для организации и т.д.Если рассматривать масштаб вовлечения и использования ресурсов, то здесьключевым будет определение того, насколько велик он для организации.Учитывая, что невозможно указать общие характеристики и критерии того,какое вовлечение ресурсов в абсолютном выражении является большим, а какоенет, можно предложить использовать набор субъективных факторов, которыемогут дать основу для определения величины масштаба использования ресурсов.К таким факторам можно отнести следующие:. доля сотрудников компании, принимающих непосредственное участие в проекте,. доля сотрудников компании, в той или иной степени вовлеченных в проект,. количество функций, которые будут поддерживаться новой информационной системой (если это не отторжение определенного набора функций существующей системы),. качественное содержание функциональности, ее сложность и охват бизнес процессов,. доля бюджета, отведенного на реализацию проекта,. стоимость проекта относительно стоимости других проектов, осуществляемых в организации в настоящий момент,. временные рамки проекта, его длительность.Соответственно на основе вышеперечисленных факторов масштаб вовлеченностиресурсов можно условно разделить на . большой, . средний и . маленький.5. Позиционирование типа изменения информационной системы:С нашей точки зрения для определенных целей имеет смысл проводитьпозиционирование типа изменения информационной системы. Это можно делатьдля того, чтобы иметь возможность сравнения планируемого проекта саналогичным, проводимым ранее данной или другой компанией. Этот формальныймеханизм может оказаться очень полезным, так как помогает быстроопределить, с какой степенью точности можно перенимать опыт при анализеаналогичного проекта. Естественно тщательное изучение одного или несколькихдругих проектов очень полезно, а в некоторых случаях может помочь взначительной экономии средств, но при первоначальной оценке необходимополучить некое формальное представление о том, какого рода проект предстоитпровести организации и в каком соотношении с другими подобными проектами оннаходится.Предлагаемая матрица содержит два типа изменений, которые выражают своегорода “степень серьезности“ проекта, то есть масштаб вовлеченности ресурсови величину или степень данных изменений, то есть вид измененияинформационной системы (рис 2.1).При этом данное позиционирование должно проводиться вместе с анализомобласти изменения информационной системы, то есть качественным анализомпроводимых изменений. Качественный анализ - неотъемлемая часть определениянабора функциональности проекта в начальной его стадии, а также основа припланировании данного проекта.|МАСШТАБ | | | ||( |большой |средний |маленький ||ВИД ( ( | | | ||( | | | || | | | ||установка | | | ||с нуля | | | || | | | ||полная смена | | | ||системы | | | || | | | ||расширение | | | ||функций | | | || | | | ||отчуждение | | | ||функций | | | || | | | ||пристройка | | | ||системы | | | || | | | ||установка | | | ||интерфейса | | | |рис. 2.1. Матрица для позиционирования типа изменения информационнойсистемы.3. Принципы планирования проекта по изменению информационной системыПланирование проекта является базовым процессом, на основе которогопроисходит все развитие и реализация проекта. Планирование можно разбить надва типа: начальное планирование и планирование в процессе осуществлениясамого проекта. Начальное планирование начинается после того, как делаетсявывод о необходимости проведения изменений в информационной системеорганизации и заканчивается, когда план проекта согласован со всемиучастниками проекта, от которых будет зависеть его реализация (менеджерыпроекта и функциональных групп, которых коснется изменение информационнойсистемы). Планирование в процессе осуществляется при необходимости внесенияизменений в проект и является рабочим процессом, зависящим от выполненияпланов реализации проекта. Рассмотрим детальнее каждый тип планированияпроекта.Начальное планирование проекта.Сначала кратко рассмотрим процесс принятия решения о проведении изменений винформационной системе. (Следует отметить, что начальная стадия любогопроекта, и в частности проекта по изменению информационной системы,является самой сложной и менее всего поддающейся структуризации, и именнопоэтому вряд ли можно провести четкое деление этой стадии на фазы, темболее что они могут следовать в разном порядке в зависимости оторганизации, от сложности ситуации и от масштаба изменений, включаявременной интервал всего планируемого проекта.)Как вообще принимается решение о проведении изменений в информационнойсистеме? Причины изменения информационной системы описаны в предыдущемразделе:. технические характеристики системы. область деятельности организации. функциональность системы. моральное устаревание системы. политика организации относительно стандартизации процессов. интеграция различных областей деятельности организации. престижность использования новой системыНа основе рекомендаций со стороны сотрудников организации или пособственным соображениям (которые также можно охарактеризовать одной извышеперечисленных причин) топ менеджмент приходит к выводу о том, чтосуществующая система не соответствует текущим потребностям организации илине будет им соответствовать в будущем. Принимается решение об измененииинформационной системы, причем детальная разработка необходимых измененийосуществляется специалистами компании из всех областей деятельности этойкомпании, которые будут затронуты при изменении информационной системы.Важное замечание: на данной стадии происходит первоначальное планированиеизменений, главная цель которого заключается в определении основныххарактеристик будущего проекта (масштаб изменений, области изменений, типинформационной системы (если происходит смена информационной системы),первоначальное определение необходимой функциональности новой системы ит.д.).На основе этого составляется начальный приблизительный план всего проекта,который проходит согласование с топ менеджментом тех функций, которыхнепосредственно коснется изменение информационной системы. После того, какпроизошло согласование, приблизительные сроки намечены, наборфункциональности определен, ресурсы, которые будут напрямую или косвеннозадействованы в проекте, выделены, начальное планирование проектазаканчивается. Далее все детальные изменения будут относиться кпланированию в процессе осуществления проекта.Рассмотрим основные составляющие, которые следует включить в начальный планпроекта:. Описание объекта изменения (что необходимо изменить - систему, часть ее функциональности и т.д.);. Краткая рекомендация по необходимости изменения (причина изменения, преимущества новой системы, описание целей, которых нужно достичь при завершении проекта);. Основные стадии проекта (см. ниже);. Основная функциональность новой или измененной системы (то есть список того, что войдет в проект) и сроки проведения изменений (если проект состоит из нескольких ступеней, результатом каждой из которых является изменение части функциональности системы, то здесь каждая ступень должна иметь четко поставленные сроки);. Список участников проекта, их основных обязанностей и ролей (менеджер проекта, топ менеджмент, ресурсы, участники и т.д.);. Бюджет проекта;. Что не войдет в проект (это необходимо для внесения ясности в ожидания менеджеров рабочих групп относительно возможностей системы);. Какие функциональные возможности системы нужно изучить в дальнейшем для потенциальной установки в дальнейшем (список);. Риски (какие факторы могут помешать реализации проекта в полном объеме, в поставленные сроки с установленным бюджетом);. Критерии успешного выполнения проекта. Список необходимых условий, от которых зависит успешная реализация проекта.Планирование в процессе осуществления проекта.Приведенная ниже схема показывает обобщенный принцип планирования проекта.Из одной из деталей данной схемы является то, что планирование в процессепроекта представляет собой непрерывный процесс, который длится дозавершения проекта. Это связано со сложностью разработки идеального плана,в котором будут предвидены все детали и возможные изменения субъективного(связанного с самим проектом) и объективного (связанного с внешнимиисточниками) характера.Рис. 3.1. Планирование проекта по изменению информационной системы.При малейших переменах (например, когда обнаруживается, что системапозволяет внедрить новый процесс с большой легкостью или когда кто-то изважных участников проекта по какой-либо причине на время выбывает изпроекта) возникает необходимость корректировки поставленных планов ивремени их реализации. Соответственно типы изменений в планах можнопозиционировать на матрице “сроки проекта - содержание проекта”.| |Сроки |проекта || |меняются |не меняются || |1. Часть |Часть || |функциональности |функциональности || |системы добавлена, |системы добавлена || |что вызывает |или удалена, но ||меняется |увеличение сроков |проект выполняется в|| |2. Часть |соответствии с || |функциональности |планом ||Содержание |системы удалена, что| || |вызывает сокращение | || |сроков | ||проекта |1. Проект не может |Изменений не || |быть завершен в |происходит, проект || |поставленные сроки в|развивается в ||не меняется |силу определенных |строгом соответствии|| |причин |с планом || |2. Проект может быть| || |завершен раньше | || |установленных сроков| || |в силу определенных | || |причин | |Рис. 3.2. “Сроки проекта - содержание проекта”Опыт показывает, что чаще всего меняются сроки завершения проекта, причем восновном в сторону увеличения. Это происходит из-за того, что в успешныхорганизациях при планировании ставятся агрессивные цели для того, чтобывдохновить сотрудников на более продуктивную работу. Поэтому когдапроисходят изменения в процессе осуществления проекта (а они как правилопроисходят в каждом серьезном проекте) возникает необходимостьзадействования дополнительных ресурсов, в том числе и времени. Если кромевремени возможно дополнительное использование такого ресурса, как наборфункций, то меняется и содержание проекта. С другой стороны, дополнительноеиспользование других ресурсов (стоимости и людей) уменьшает необходимостьувеличения времени, то есть сокращает сроки выполнения проекта.Планирование в процессе осуществления проекта происходит на каждой стадиипроекта на регулярной основе. Более того, по мере продвижения проекта покаждой из стадий часто целесообразно организовывать собрания основныхучастников проекта для определения текущего положения дел и сравнения спланом. Регулярность таких собраний зависит от длительности проекта и егомасштаба. Если между текущим положением дел и планом намечается разница, тов первую очередь производится анализ способов устранения отставания, а приневозможности устранить отставание изменяется план проекта, чтосогласовывается с топ менеджментом на регулярных собраниях (см. ниже).При переходе с одной стадии на другую составляется детальный планреализации новой стадии проекта в соответствии с изменениями в планах, еслитакие имеются.Стадии проекта по изменению информационной системы.Здесь автор предложил бы сконцентрировать внимание на таких изменениях, какустановка новой системы при отчуждении старой (сюда в основном относятсятакие виды изменения системы, как полная смена системы, расширение функций,а также иногда установка с нуля), потому что именно такие измененияпредставляют наибольший интерес, являются наиболее сложными и требуют болеевнимательного изучения, так как во многом связаны не только с техническимирешениями, но и с вовлечением людей их разных функций и с взаимоотношениямивнутри организации.В разных организациях существуют разные подходы по планированию изменений.Тем не менее можно наметить общие блоки, или части, из которых состоитпроект по изменению информационной системы практически для любойорганизации (началом проекта в данном случае автор предложил бы считатьмомент, когда начальное планирование проекта завершено, необходимыесогласования сделаны и ресурсы для участия в проекте выделены):. Описание бизнес процессов. Тренинги по новой системе (при необходимости). Тестирование функциональности системы. Необходимые доработки. Обучение пользователей функциональности системы. Тестирование системы пользователями. Ввод реальных данных. Переход на новую системуРассмотрим более детально каждую стадию.Описание бизнес процессов.Для того, чтобы иметь четкое представление о том, какие конкретно процессыбудут подвергаться изменениям и каким образом при изменении информационнойсистемы, нужно иметь четкое формальное описание существующих процессов.Детальность такого описания должна быть на уровне концепции процесса иосновных его составляющих, а также входящих и выходящих ресурсов. Например,если это процесс обработки заказов, то нужно создать общее описаниепроцесса (с чего начинается, из чего состоит и чем заканчивается, в какоевремя происходит какая стадия этого процесса, какие параметры существуют узаказов, например условия оплаты, классы заказчиков, категории услуг ипродуктов, с каких складов осуществляются отгрузки и т.д.). Пример такойсхемы приведен в Приложении 1 (Прием заказа). При описании бизнес процессовможет оказаться полезным создание схем, потому что они наглядно показываютосновные составляющие процесса.Описание бизнес процессов является не только базой, по отношению к которойбудет меняться процесс, но также описание процессов является некиммеханизмом оценки возможных изменений и критерием, которому должнасоответствовать новая схема измененного бизнес - процесса.Описание бизнес - процессов осуществляется в самом начале проекта, арезультат этой стадии - наличие свежего сборника документации по процессаморганизации - является той информационной базой, с помощью которойформируется содержание изменений в ходе проекта.Тренинги по новой системе (при необходимости).Тренинги необходимы в случае, когда непосредственные участники проекта незнакомы с системой. Для того, чтобы у участников проекта сформировалосьопределенное представление о новой системе, приглашают специалистов (этомогут быть как внешние консультанты, аудиторы или разработчики системы, таки сотрудники данной организации, например из другого филиала, где системауже установлена).Следует отметить, что нет необходимости в прохождении детального тренинга,то есть такого тренинга, который даст полное представление о том, каксистема может работать в других организациях. Это объясняется уникальнойспецификой бизнес - процессов каждой организации, обусловленной бизнестехнологиями, спецификой региона или отрасли. Участники проекта могутпрослушать курс по базовой функциональности системы с объяснением техпринципов настройки тех параметров (системных настроек), с помощью которыхможно создать необходимую инфраструктуру для осуществления бизнес -процессов. Фактически это означает, что основной задачей участников проектав дальнейшем будет моделирование бизнес процессов организации, причем онодолжно быть основано на принципе удовлетворения необходимых потребностейорганизации, а не использования существующий возможностей системы.Тестирование функциональности системы.После прохождения тренинга участники проекта начинают тестировать систему.Фактически это означает начало моделирования процессов в системе,содержательным стержнем которого служит та документация, котораясоздавалась при описании бизнес - процессов. Происходит проверкавозможности системы обрабатывать в себе ту информацию, которая циркулируетв организации. Это очень важный этап, потому что именно здесь закладываетсяоснова того, что в дальнейшем будет называться системой данной организации.Все дальнейшие стадии будут напрямую зависеть от этой, а содержание этихстадий будет являться производной от того, что будет заложено на данномуровне. При тестировании системы создается документация по описаниюфункциональных возможностей системы, а также начинают формироватьсяметодические материалы, описывающие, как в системе выглядит тот или инойпроцесс; в дальнейшем такая документация будет использоватьсяпользователями системы.Также одним из ключевых моментов автору видится в том, что именно на даннойстадии должны произойти все согласования с будущими пользователями системыи их менеджерами по приемлемости возможностей системы.Необходимые доработки.В случае, когда обнаруживается, что система не позволяет осуществлять какой-нибудь важный процесс (или в системе не существует необходимого приемлемогонабора отчетности), формируются запросы на разработку дополнительнойфункциональности.Разработка может осуществляться как внешними специалистами, так ивнутренними. Данная стадия происходит как правило в параллели с предыдущейи иногда даже с последующей (например, когда доработки не носятсущественного характера и не могут помешать обучению пользователей идальнейшему тестированию системы).На данной стадии может измениться содержание проекта, причем как в сторонусокращения части внедряемой функциональности, так и в сторону еерасширения, которое во многом это также зависит от бюджета проекта.Обучение пользователей функциональности системы.После того, как функциональность системы протестирована, необходимыедоработки сделаны, наступает стадия, которая является прелюдией к шлифовкесистемы. Участники проекта начинают обучать пользователей работе ссистемой. Это необходимо не только для того, чтобы они смогли качественнопротестировать систему и выдать свои рекомендации, но также и для того,чтобы они привыкли к системе и натренировались для дальнейшего эффективноговключения в работу с новой системой (так называемый “training on the job”),а потенциально возможный негативный настрой растворился в изучениивозможностей системы и предварительной работе с ней.Тестирование системы пользователями.Несмотря на то, что система тестировалась участниками проекта, как быхорошо они не разбирались в процессах организации, у непосредственныхучастников рабочих процессов (будущих пользователей системы) развитогораздо более детальное представление об этих процессах. Пользователи могутзнать достаточно различных “подводных камней”, которые выясняются толькочерез определенное время и которые очень сложно учесть в описании процессовлюдям, которые не участвуют в процессах на регулярной ежедневной основе.Это объясняется еще и тем, что ситуация в бизнесе постоянно меняется,меняются с ней и бизнес - процессы, причем такие изменения могут быть какзначительными, так и совершенно незаметными.В ходе тестирования проверяется качество системы, ее полнота и готовность квнедрению. Здесь многое зависит от участников проекта. Под ихответственность особенно должно попасть следующее:. разработка набора сценариев тестов для пользователей: . тесты, проверяющие функциональность системы; . тесты, проверяющие взаимодействие в системе между разными рабочими группами, что напрямую связано с циркуляцией информации по системе;разработка сценариев должна производиться участниками проекта, потому что только они имеют так называемый вид сверху на процессы, причем более детальный, чем менеджеры рабочих групп, а пользователи как правило не имеют такого представления о процессах в целом, являясь экспертами в своей области;. составление расписания (графика) тестирования - когда кто из пользователей должен протестировать какой участок функциональности; здесь особое внимание следует уделить согласованию данного расписания с менеджерами и контролю за дисциплиной следования расписанию (потому что у пользователей есть свои прямые обязанности по работе, они для них как правило являются первоприоритетными по отношению к тестированию новой системы, что является тем фактом, который требует дополнительно внимания со стороны и участников проекта, и менеджеров);. изучение мнения пользователей о системе, обсуждения ее возможностей и детальный анализ необходимости в дополнительных доработках;. проведение формальной аттестации пользователей по знаниям новой системы и сообщение результатов менеджерам как некий механизм присвоения квалификации и подведения итогов по готовности пользователей по работе с системой.Ввод реальных данных.После того, как все необходимые детали по работе системы согласованы спользователями, система признается готовой к установке, а топ менеджментпринимает окончательное решение о внедрении (так называемое “go-no-gosolution”), начинается сам переход с одной системы на другую.Этот переход начинается с ввода реальных данных в новую систему. Опытпоказывает, что наиболее эффективным является начало ввода данных впараллели с вводом в старую систему (хотя возможен и вариант резкогоперехода, но его рекомендуется проводить только когда переход на новуюсистему не представляет особой сложности, является стандартным хорошоизученным решением, с успехом применяемым ранее). Это требуетдополнительного напряжения со стороны пользователей, потому что в течениекакого-то времени ( день, неделя или даже больше) им придется работать вдвух системах одновременно вместо одной. Привлекать людей со стороны нерекомендуется, потому что это дорого, для этих людей нужно провести хорошийтренинг (несмотря на который вероятность ошибок все равно велика), чтозанимает время, которого в конце проекта становится катастрофически мало.Ввод данных (все системные настройки должны быть уже введены в систему настадии тестирования системы пользователями) начинается с ввода такназываемых мастер - данных:. заказчики, их адреса, контактные лица и т.д.;. список продуктов с необходимыми характеристиками, такими, как количество штук в коробке, размеры, вес, коды и т.д.;. цены и скидки - как на продукты (закупочные и продажные), так и на другие услуги (перевозки, консультации, денежные переводы и т.д.);. склады, их адреса, контактные лица и т.д.;. поставщики, их адреса, контактные лица и т.д.;. другие партнеры (перевозчики, консультанты, банки и т.д.);. транспорт, характеристики машин (объем, тип, номера и т.д.);. другое.Затем начиная с определенного момента, когда все базовые данные введены, всистему начинает вводиться рабочая информация, соответствующая бизнес -процессам.Это начинается с ввода начальных балансов (количества продукции на складах,счета к оплате и счета к получению, кредитный статус заказчиков, открытыезаказы и т.д.), как правило в выходные дни. Потом начиная со следующегорабочего дня начинается параллельный ввод данных в две системы - новую истарую.Параллельный ввод данных длится до тех пор, пока в новую систему непоступит вся необходимая информация для начала самостоятельной (то есть безпомощи данных в старой системе) работы - например, когда все не отгруженныезаказы, которые существовали в старой системе, были или введены в новую,или отгружены в старой системе и попали в архив.Переход на новую систему.Переход на новую систему означает прекращение ввода данных в старую системуи начало (продолжение, если переход был плавным, как это было описано выше)ввода данных только в новую систему.4. Принципы формирования и работы команды, отвечающей за изменение информационной системы, подбор ее участников и взаимоотношения с организациейЕсли посмотреть на организацию, вовлеченную в реализацию крупного проекта,то та ее часть, которая так или иначе задействована в данный проект,сравнима с айсбергом, у которого с первого взгляда видна только одна треть,а остальная часть скрыта под водой. Точно так же при первом знакомстве стакой организацией сначала внимание привлекает только команда сотрудников,непосредственно работающих над проектом, то есть самих участников проекта.Однако по мере того как происходит более детальное изучение взаимоотношенийвнутри данной организации, становится видно, что на самом деле в проект втой или иной степени вовлечены также и многие другие сотрудникиорганизации, в непосредственные обязанности которых входит текущаяуправленческая или оперативная деятельность, то есть поддержание рутинныхбизнес - процессов организации. Рассмотрим сначала структуру командыучастников проекта и взаимоотношения внутри команды, а затем перейдем нарассмотрение всей организации и взаимоотношений команды с организацией вцелом (автор снова предложил бы сконцентрироваться на таких типахизменений, которые характеризуются внедрением новой системы вместе сотчуждением старой при среднем или большом масштабе вовлечения ресурсов,потому что именно такие типы изменений позволяют рассматривать всюмногогранность вопросов, связанных с изменением информационной системы).Структура команды участников проекта и взаимоотношения между ними.В команде участников во первых должен быть менеджер проекта. В егообязанности входит руководство над проектом в целом, планирование стадийпроекта и отчетность перед топ менеджментом.Следующее звено участников проекта составляют менеджеры отдельной области,в которой устанавливается информационная система, например финансы илогистика (следует заметить, что если проект не требует большого вовлеченияресурсов, то менеджер проекта может выполнять роли менеджеров областей иливсех участников проекта, а предлагаемая схема лишь описывает ту необходимуюструктуру, на которую должно опираться руководство при определениипринципов подбора команды участников проекта). В тесном сотрудничестве сменеджерами функций работают специалисты из группы информационныхтехнологий (IT). В обязанности менеджеров отдельных областей проекта, илифункций, в большей степени входит разработка требований к системе,тестирование системы, более детальное планирование внутри каждой стадии инепосредственное общение с сотрудниками организации. На сотрудников ITвозлагаются более технические задачи по тестированию системы и еепараметров, общение с разработчиками по техническим вопросам, техническоепланирование (связанное с техническими деталями проекта) и т.д.В крупный проект при необходимости также могут быть включены сотрудники,входящие в группы менеджеров проекта по функциям или в группы сотрудниковIT, отвечающие за более детальное выполнение каждой конкретной задачи иликомплекса задач.После такого своего рода механистического описания ролей, возлагаемых научастников проекта (как упоминалось ранее, подобные роли должны бытьрасписаны в начальном плане проекта; как выдержка из реального начальногоплана проекта такое описание приведено в приложении 2) автор счелнеобходимым отметить одно важное замечание. Поскольку каждый проект,представляет собой нечто, которое можно охарактеризовать как имеющееспецифические особенности и центробежное стремление к развитию, результатомчего на непродолжительный период в любой момент времени может стать некаяструктура, по своим уникальным характеристикам схожая с реальнымижизненными ситуациями, то очень важно не упустить из виду неформальныестороны рабочих взаимоотношений участников проекта. К таким неформальнымсторонам взаимоотношений напрямую относится совместная работа надбольшинством вопросов по проекту. Именно командная работа отличаетбольшинство проектов, причем на время существования проекта происходитформирование межфункциональных групп, что позволяет комплексно подходить крешению проблем в различных областях деятельности. В процессе проектавыполнение задач часто не делится между участниками (IT отвечает затехнические задачи, а менеджер по функции - за бизнес - процессы),наоборот, участники вместе работают над выполнением каждой задачи, чтозанимает больше времени, но позволяет учесть гораздо больше нюансов,выработать общность взглядов, достичь “синергического” эффекта и к тому жепостроить такую структуру, в которой один сотрудник может заменить другогов случае необходимости.Взгляд на организацию в период реализации проекта.После того, как топ менеджмент принимает решение о начале проекта иформирует команду, в структуре организации или по крайней мере той еечасти, которая так или иначе будет затронута в процессе проекта и егореализации, начинают происходить изменения. Данные изменения заключаются втом, что в связи с проектом на фоне рутинных процессов выделяется новаяформа организации людей, которые оказываются вовлеченными в проект.Если рассмотреть предназначение всего проекта под углом тех результатов,которые проект должен выдать, предварительно переработав некие ресурсы иинформацию, которая была на входе, то сообщество людей, принимающих участиев этом процессе, и их взаимоотношения можно описать следующим образом.В проекте принимают участие следующие группы людей (рис 4.1.), роли которыхбудут описаны чуть ниже:1. Топ менеджмент2. Менеджер проекта3. Участники проекта4. Ключевые ресурсы5. Менеджеры ключевых ресурсов6. Пользователи7. Менеджеры пользователейРис 4.1. Группы людей, принимающих участие в проекте.Рассмотрим более детально каждую из групп.Менеджер проекта и участники проекта несут основную нагрузку по анализуинформации и преобразованию ее в требуемый результат. В проекте поизменению информационной системы данные люди анализируют возможностиосуществления бизнес - процессов в новой системе. Во многом их деятельностьзаключается в моделировании процессов в системе (которая в данном пониманииявляется некой базой, по которой строятся процессы). Однако сам дизайнновой системы задается требованиями, которые предъявляются к системе состороны всех заинтересованных сотрудников. Здесь автор сознательно нерасписывает группы людей, которые могут повлиять на требования к системе,потому что возможность повлиять на требования к системе должна быть укаждого сотрудника, потому что нередко даже случайные идеи, высказанныечеловеком, который не имеет прямого отношения к процессу, могут развиться взначительные изменения, которые могут повлечь за собой улучшения процессовили минимизацию ресурсов, задействованных в процессах организации (этоможет произойти от того, что люди, мышление которых не связано устоявшимисясхемами в какой-то области, гораздо легче могут выйти за границы,диктующиеся данными схемами - так называемый эффект “thinking out of thebox”).Результатом деятельности данной группы является внедренная в установленныесроки (и без потерь качества работы при внедрении) система, удовлетворяющаятребованиям, предъявленным к этой системе.Ключевые ресурсы - это сотрудники, обладающие экспертными знаниями вобласти своих бизнес - процессов. Их общение с участниками проекта строитсяна передаче участникам проекта своих знаний о процессах организации иоказании консультаций по всем вопросам, тонкостям и возможным ситуациям,связанным с процессами в организации. Фактически ключевые ресурсы играютроль трансляторов информации о текущих процессах, которая передается людямпреобразующим эти процессы в новые.Роль менеджеров ключевых ресурсов заключается в выделении ключевыхресурсов, согласовании степени их занятости по проекту с участникамипроекта (в основном с менеджерами функций проекта) и контроле заправильностью подтекста передачи информации. Под подтекстом имеется в видунаправленность информации, выделение основных блоков и под процессов,постановка акцентов на ту или иную деталь, которой с точки зренияменеджеров следует уделить особое внимание.Пользователи - это те люди, которые будут работать в системе после еевнедрения. Именно их анализ и тестирование системы представляет собойпроверку системы на качество. Эти люди (нередко они же и являются ключевымиресурсами) помогают участникам проекта определить те изъяны, которыесуществуют в системе, помогают моделировать процессы с точки зренияприемлемого результата и предоставляют свое экспертное заключение о работесистемы в целом.Менеджеры пользователей - это люди, которые получают непосредственнуювыгоду от внедрения системы. В качестве улучшений можно привести нескольконаглядных примеров:. сокращение количества своих сотрудников или требуемого времени на работу с системой и с процессами,упрощение потока информации - например прекращение подготовки дополнительных отчетов для передачи данных в другую группу и начало использовать для этих целей функциональность системы,. автоматизация некоторых алгоритмов действий - например автоматическая проверка на наличие товара на складе или автоматический кредитный контроль,. создание электронной связи между различными звеньями процессов - например интеграция склада в информационную систему,. дополнительные возможности отчетности для оперативной или аналитической деятельности,. и т.д.В задачи менеджеров входит формирование требований к новой информационнойсистеме. Формирование требований основывается на представлении менеджеров обизнес - процессах в целом, знании о возможностях улучшения процессов.Здесь нужно подчеркнуть важность совместной работы менеджеров и участниковпроекта, особенно менеджеров по функциям. Совместный анализ улучшений исистемных возможностей к этому является ключевым фактором успеха проекта.Топ менеджмент осуществляет общий контроль за ходом проекта. Следуетотметить, что сфера влияния топ менеджмента относится ко всему, что имеетотношение к проекту. Поскольку топ менеджмент отвечает за организацию вцелом, то в его интересы входят все составляющие проекта:. правильное формирование вводных данных в проект (здесь за качество данных отвечают менеджеры ключевых ресурсов и участники проекта, а подход к установлению правильных взаимоотношений при таком сотрудничестве должен сформировать именно топ менеджмент для избежания конфликтов в распределении ресурсов и ролей),. правильное формирование требований к системе (в сущности при принятии решения об установке новой системы топ менеджмент уже имеет заключения своих сотрудников о тех желаемых изменениях, которые должны произойти при смене системы, в задачи топ менеджмента входит правильная расстановка акцентов в соответствии со своим видением процессов; топ менеджмент формирует своего рода задачи, или цели относительно процессов, а способы реализации этих целей с помощью новой системы возлагаются на менеджеров пользователей и участников проекта, как упоминалось ранее),. и правильное управление проектом (поскольку в конечном счете именно топ менеджмент заинтересован достижении целей проекта, он должен осуществлять поддержку при любых осложнениях, будь то конфликтные ситуации в организации, связанные с проектом, или необходимость выделить дополнительные средства и ресурсы на проект, или изменения в сроках проекта и функциональности системы, или какие-то другие случаи; если смотреть на проект с точки зрения менеджера проекта, то в его приоритетные обязанности должно входить своевременное информирование топ менеджмента и других сотрудников, имеющих отношение к проекту, об отклонениях от первоначальных планов проекта и всех осложнениях).И в заключение рассмотрим организацию и типы собраний, которые могут бытьсредством формализованного общения между различными группами, принимающимиучастие в проекте. Для этого обратимся к таблице, которая даст болеедетально представление о тех собраниях, которые могут быть полезными приработе с проектом.|Тип собрания |Цель |Участники |Регулярность |Содержание собрания ||Начальное |Объявить о |Топ менеджмент, |1 раз в начале |Объявление о запуске ||собрание |начале проекта и|менеджер проекта, |проекта, далее при |проекта || |его важности |участники проекта, |значимых изменениях в | || | |заинтересованные |проекте | || | |функциональные | | || | |менеджеры | | ||Собрания |Обсудить текущий|Топ менеджмент, |В зависимости от |Обсуждение текущего ||руководства и |статус проекта и|менеджер проекта, |длительности проекта: |статуса проекта, ||участников |согласовать |участники проекта |1 раз в неделю, месяц |изменений в проекте, ||проекта |дальнейшие планы| | |проблем, согласование с|| | | | |топ менеджментом его || | | | |поддержки при || | | | |необходимости ||Планирование |Детально |Менеджер проекта, |При приближении |Разработка и ||следующих стадий|спланировать и |участники проекта |завершения очередной |согласование планов и || |согласовать | |стадии |выявление потенциальных|| |дальнейшие | | |проблем || |работы по | | | || |проекту | | | ||Согласование |Согласовать |Участники проекта, |В начале проекта, при |Обсуждение требований ||требований к |требования к |менеджеры |возможных изменениях в|по процессам, анализ ||системе |системе |пользователей |функциональности |возможности технической|| | | |устанавливаемой |реализации данных || | | |системы |требований в системе, || | | | |поиск альтернативных || | | | |решений ||Встречи с |Согласовать |Менеджер проекта, |При приближении |Информирование о ||пользователями |текущий статус, |участники проекта, |тестирования и запуска|текущем статусе, || |дальнейшие планы|пользователи, |системы, когда |объявление о начале || |и вовлеченность |менеджеры |необходимо вовлечение |тестирования, об || |пользователей |пользователей |пользователей |участии в переходе на || | | | |систему, о любых || | | | |изменениях в планах ||Аудиторские |Оценить |Менеджер проекта, |При приближении |Проведение проверки ||оценки (при |надежность и |участники проекта, |запуска системы |надежности и качества ||необходимости) |качество системы|аудиторы, | |системы || | |пользователи | | |Приложение 1. Прием заказа.1. Прием заказа: 2. Заказ принимается по: 3. Электронной почте 4. Факсу 5. Телефону 6. Типы заказов: 22 паллетные, 33 паллетные а/м, ж/д вагоны или контейнеры 7. Типы транспортировки: 8. Доставка транспортом компании 9. Самовывоз10. При необходимости корректировки заказа - оператор звонит заказчику и согласовывает изменения в заказе11. Ввод заказа в систему: 12. Заказ (заголовок): 13. Покупатель 14. Номер заказа 15. Требуемая дата доставки 16. Дата обработки заказа 17. Дата действия прейскуранта 18. Заказ (строчки): 19. Код товара 20. Кол-во коробок 21. Единица измерения (коробка)22. Заказ трансформируется в Поставку: 23. Поставка (заголовок): 24. Получатель 25. № поставки 26. Вес поставки 27. Дата отгрузки (предлагается системой) 28. Поставка (строчки): 29. Код товара 30. Кол-во коробок 31. Единица измерения (коробка) 32. Кредитный контроль (разрешение/ блокировка/ изменение заказа) и проверка на наличие товара (товар есть/ товара нет ( изменение заказа) осуществляются системой33. Сравнение заказа и измененного заказа: генерирование отчета об отказах34. Окончательное согласование заказа при необходимости: 35. Изменения согласовываются по телефону 36. Оператор подтверждает заказ 37. Заказчику сообщается номер заказа и сумма к оплате38. Транспортная группа согласовывает доставку товара 39. Отчет о заказах к отгрузке 40. Заказ на перевозку 41. Ввод транспортных данных в систему42. Распечатка заказа43. Формирование подборки заказа в системе для склада: 44 Заголовок: 45. Получатель 46. № поставки 47. Дата отгрузки 48. Общий вес 49. Строчки: 50. Склад 51. Камера 52. Товар 53. Количество 54. Единица измерения (коробки) 55. Подобранное количество 56. Единица измерения (коробки) 57. Сохранение изменений58. Разноска (пост)59. Оформление и распечатка счета60. Генерирование отчета об открытых заказах61. Генерирование отчета о разрешенных заказахПриложение 2. Выдержка из начального плана проекта.Project OrganisationProject Sponsor Person а F&аManager Russia Person B Logistics Manager RussiaOther Board Members Person C IT Manager RussiaSteering Team Person D Person E Person F Person GProject Manager Person H IT Project ManagerProject TeamIT: Person I IT Analyst Person J IT AnalystF&A: Person K F&аClerkLogistics: Person L Logistics Project ManagerLogistics: Person M Logistics Project AssistantWarehouse: Person N Warehouse ManagerLocal ResourcesLogistics: 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 ManagerWarehouses: Person V Warehouse “A” Person W Warehouse “B” Person X Warehouse “C”F&A: Person Y Accounting Manager Person Z GL Supervisor Person Aа Banking Manager Person AB Profit ForecasterIT: 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 AdministratorExternal Resources SAP R/3 RSG EMEаImplementation Support Team SAP Consult C.I.S.Stakeholders F&аanalysis Sales Department Marketing Department Platinum RSGKey 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----------------------- люди сто- имость набор функций время 100% Принятие решения о необходимости изменений Начальное планирование проекта Планирование в процессе Внесение изменений Есть необходимость проведения изменений?ДаНет Контроль за успешным выполнением плана Менеджер проекта Команда Ключевые ресурсы Менеджеры Менеджеры Пользователи ПРОЕКТ ВХОД ВЫХОД ОРГАНИЗАЦИЯ Топ менеджмент




Похожие:

Реорганизация бизнес-процессов при изменении информационной системы в крупной организации iconРеорганизация бизнес процессов при изменении информационной системы в крупной организации
Принципы формирования и работы команды, отвечающей за изменение информационной системы, подбор ее участников и взаимоотношения с...
Реорганизация бизнес-процессов при изменении информационной системы в крупной организации iconАннотация учебной дисциплины «Управление бизнес-процессами» программы профессиональной переподготовки «Информационная бизнес-аналитика»
Цель: получение теоретических знаний и практических навыков по описанию, анализу и совершенствованию бизнес-процессов организации...
Реорганизация бизнес-процессов при изменении информационной системы в крупной организации iconРеинжиниринг бизнес-процессов: моделирование и оптимизация
Диагностика системы управления, структуры и иерархии существующих бизнес-процессов
Реорганизация бизнес-процессов при изменении информационной системы в крупной организации iconПрактикум по моделированию бизнес-процессов, бизнес-функций, описанию документов при моделировании, моделированию сценария поведения объектов с использованием case-средства Rational Rose по дисциплине «Информационные технологии»
«Моделирование бизнес-процессов при проектировании программных систем с использованием case-средства Rational Rose» 3
Реорганизация бизнес-процессов при изменении информационной системы в крупной организации iconПрактикум по моделированию бизнес-процессов, бизнес-функций, описанию документов при моделировании, моделированию сценария поведения объектов с использованием case-средства Rational Rose по дисциплине «Информационные технологии»
«Моделирование бизнес-процессов при проектировании программных систем с использованием case-средства Rational Rose» 3
Реорганизация бизнес-процессов при изменении информационной системы в крупной организации iconБухгалтерский учет в информационной системе управления экономикой организации
Таким образом, бухгалтерский учет является составной частью управленческой и информационной системы организации
Реорганизация бизнес-процессов при изменении информационной системы в крупной организации iconУчебной дисциплины «Автоматизация анализа и документирования бизнес-процессов»
Цель: получение теоретических знаний о методологии и инструментарии для анализа и документирования бизнес-процессов, а также практических...
Реорганизация бизнес-процессов при изменении информационной системы в крупной организации iconМинистерство экономического развития и торговли Российской Федерации Государственный университет Высшая школа экономики Факультет «Бизнес-информатика»
Основные понятия о скриптах. Моделирование предметных областей деятельности организации. Совершенствование процессов и теоретические...
Реорганизация бизнес-процессов при изменении информационной системы в крупной организации iconАннотация учебной дисциплины «Управление информационной безопасностью» программы профессиональной переподготовки «Менеджер в сфере бизнес-информатики»
Цель курса: сформировать систему знаний о принципах, методах, подходах и инструментах эффективного управления информационной безопасностью...
Реорганизация бизнес-процессов при изменении информационной системы в крупной организации iconУчебной дисциплины «Моделирование и анализ бизнес-процессов»
Цель: изучение теоретических основ процессного управления, моделирования и анализа процессов, а также освоение методических рекомендаций...
Разместите кнопку на своём сайте:
Документы


База данных защищена авторским правом ©rushkolnik.ru 2000-2015
При копировании материала обязательно указание активной ссылки открытой для индексации.
обратиться к администрации
Документы