Показать сообщение отдельно
Старый 15.12.2001, 22:31   #6  
Елена Сысовская is offline
Елена Сысовская
Участник
Аватар для Елена Сысовская
 
499 / 25 (1) +++
Регистрация: 30.11.2001
Адрес: планета Земля
Наброски 6. Замечания к ППО (Найденова).
Замечания к документу
"План предпроектного обследования предприятия."


ред 3.

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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