Основные стадии проекта разработки и внедрения КИС
Подобная ситуация аналогична той, когда обоснование применимости или тестирование программного модуля поручают написавшему его программисту. С другой стороны, проект внедрения КИС никогда не должен носить софтверный оттенок, так как основной его целью является оптимизация управленческой инфраструктуры.
Поэтому, проектным управлением должны заниматься не специалисты по конфигурированию программного обеспечения, а профессиональные бизнес-консультанты.
Основные стадии проекта разработки и внедрения КИС
включают:
- Анализ опыта других предприятий (обычно близких по профилю, отрасли, рынку, методам ведения бизнеса и т.д.), связанного с внедрением КИС.
- Определение целей проекта в контексте повышения эффективности решения существующих управленческих задач и возможности внедрения принципиально новых управленческих технологий.
- Определение укрупненных показателей эффективности бизнес-процессов, подлежащих автоматизации (целевых бизнес-процессов), и формирование первоначальных критериев успешности проекта.
- Определение приемлемого финансового плана-графика проекта.
- Организация тендера и выбор управляющей (внедряющей) компании. Выбор управляющей компании обычно играет решающую роль с точки зрения общей результативности проекта. Самые серьезные риски чаще всего обусловлены некачественным управлением проектом (project management), поэтому ошибка в выборе управляющей компании может грозить серьезными неудачами.
При анализе претендентов следует руководствоваться следующими главными факторами: наличие формализованной (отчуждаемой) методологии управления проектом, высокая деловая репутация компании, присутствие квалифицированных консультантов и бизнес-аналитиков, позитивный опыт работы в аналогичных проектах.
- Подготовка персонала компании к проекту изменений,
разработка новой политики мотивации труда. Почти во всех случаях проведения серьезных преобразований на предприятии возникает противодействие (как активное, так и пассивное) сотрудников на разных уровнях организационной иерархии. Это обусловлено характерной человеческой особенностью, выражающейся в опасениях по отношению к любым нововведениям, боязни утратить свою незаменимость, неготовности принимать решения и т.д.
Как показывает практика, существенно уменьшить сопротивление персонала, а во многих случаях даже вызвать его заинтересованность в отношении проекта позволяет тщательная проработка новой политики мотивации труда. Другими факторами, эффективно сказывающимися на преодолении этой проблемы, являются: создание у сотрудников твердого убеждения неизбежности нововведений, поддержание высокого статуса проекта и закрепление всех проектных распоряжений соответствующими приказами руководства.
- Утверждение проектной методологии. Обследование и реорганизация (в том случае, если она проводится) предприятия являются первым этапом проекта внедрения, и их результаты определяющим образом влияют как на дальнейшую конфигурацию КИС, так и на соответствие результатов ожиданиям Заказчика. Поэтому уже на этом этапе всегда необходимо утверждать единую концепцию управления проектом и строго следовать ей на всех последующих стадиях, при необходимости внося в регламент коррективы, обусловленные новой предметной областью.
Проектная методология управления базируется на управлении интеграцией, содержанием, временем, стоимостью, качеством, человеческими ресурсами, коммуникациями, риском, обеспечением проекта. За основу берется процессная модель и выделяется до 37 процессов, каждый из которых описывается в виде входо-выходных модулей с описанием инструментария и технологии преобразования данных.
Например, модель команды определяет ролевой состав рабочей группы, правила взаимодействия между ролями и ответственность за выполнение проектных задач. Модель процессов описывает регламент выполнения работ, отчетную политику и правила предоставления результатов на протяжении всего жизненного цикла проекта.
Модель рисков описывает правила выявления и отслеживания статусов рисков, а также принципы поиска решений по их устранению или плановому снижению последствий от их актуализации.
- Управление проектом организационных изменений.
- Утверждение модели управления проекта.
- Разработка и утверждение плана-графика обследования.
- Управление проектом обследования. Построение и утверждение бизнес-модели как есть.
Представление и согласование полученных результатов.
- Анализ бизнес-модели как есть, разработка и утверждение бизнес-модели как должно быть, планирование проекта реорганизации. Разработка технического задания на реорганизацию. Даже в тех случаях, когда поставщики программного обеспечения утверждают, что внедрение возможно по принципу как есть, они выдают желаемое за действительное, так как всегда наличие КИС подразумевает новые методы работы с информацией, а соответственно и новую бизнес-модель предприятия.
Только в этом случае изменения будут продиктованы конфигурацией программного обеспечения, а не реальными показателями эффективности бизнес-процессов.
- Управление проектом реорганизации бизнес-процессов
и отдельных подсистем (например, системы мотивации) предприятия согласно техническому заданию. Очень часто случается, что этим этапом пренебрегают и, в результате, автоматизация не дает никаких ощутимых результатов. Внедрение КИС оправдано лишь в тех случаях, когда деятельность предприятия соответствует стратегии развития и все методы управления, лежащие в основе требований по функциональности программного обеспечения уже имеют свой утвержденный регламент.
Другими словами, нет никакого смысла покупать программный модуль Бюджетирование и внедрять его, если сама система бюджетирования на предприятии отсутствует. То же самое можно сказать об оперативности обработки и доставки управленческой информации.
Если в этом процессе возникают ситуации, когда задержки вызваны организационными проблемами, то и при наличии КИС требуемой полноты и актуальности информации добиться невозможно. Не следует забывать о том, что если планируется внедрение КИС класса MRPII, то для начала нужно определиться с тем, как будет разрабатываться политика планирования производства с учетом новых условий, и уже потом разрабатывать техническое задание по настройке и адаптации программного обеспечения.
Таким образом, в компании должен быть утвержден проект реорганизации бизнес-процессов, включающий механизм принятия обоснованных решений по изменению структуры (см. соответствующие формальные модели во второй части настоящей работы) в связи с требованием текущей обстановки. В общем виде основные этапы реорганизации представлены на рисунке 9.
- Утверждение новой бизнес-модели как есть, соответствующей бизнес-процессам предприятия после осуществления реорганизации.
- Конкретизация целей и критериев успешности проекта построения КИС.
- Разработка функциональных и технических требований к программному обеспечению.
- Выбор поставщика программного обеспечения. Формулирование требований к программному обеспечению (функциональность, открытость, адаптируемость математической модели, технические требования, безопасность, интерфейс, документация, наличие успешно реализованных проектов).
Программное обеспечение, предназначенное для внедрения в качестве базиса КИС, обладает одним общим характерным свойством: оно сложно для оперативного ознакомления. Эта проблема обусловлена следующими факторами:
o Сложность не только внутренних механизмов работы, но и наблюдаемой функциональной структуры.
о Большой набор специфических инструментов для различных областей менеджмента. Например, многие производственные и технологические тонкости неизвестны финансовому директору, и наоборот, главный инженер некомпетентен в принципах анализа финансовых отклонений.
Специалист, принимающий решение по выбору программного комплекса, как правило, является IT-менеджером и имеет лишь общее и неполное представление об использующихся управленческих методиках.
о Наличие специальной терминологии, большого количества стандартов и псевдостандартов информационного менеджмента (очень часто общие концепции называют стандартами или вообще ориентируются на стандарты, являющиеся частью маркетинговой политики некоторых разработчиков).
о Доступность материалов исключительно рекламного характера, фактическое отсутствие описания реального опыта использования программного комплекса и истинной статистики внедрений.
- Формулирование требований к поставщику программного обеспечения (политика ценообразования, форма контракта, принципы обслуживания и поддержки, кадровые возможности, финансовая стабильность).
- Утверждение требований по форме и графику предоставления информации претендентам.
- Разработка требований к форме презентации, подготовка модельных примеров.
- Рассылка тендерной документации и организация тендера. Выбор поставщика решения или принятие решения об индивидуальной разработке.
- Определение формы сотрудничества и заключение контракта на поставку программного обеспечения.
- Управление проектом построения и развития КИС
- Утверждение модели управления, в том числе: модели команды (рабочей группы проекта), модели процессов и модели рисков и т.д.
- Внесение в бизнес-модель корректив, обусловленных развитием компании (если необходимо). Разработка и утверждение информационной модели.
- Разработка и утверждение плана-графика работ. Конфигурирование и развитие КИС следует осуществлять в соответствии с принципом версионности.
Длительность работ по созданию одной версии не должна быть очень большой (обычно не более года). Это связано со скоростью изменения бизнес-модели (связанной с развитием компании) и с прогрессом в отрасли информационных технологий.
Подход к внедрению должен быть итеративным (циклическим): когда один цикл внедрения близок к завершению, должен планироваться следующий.
- Управление настройкой и адаптацией программного обеспечения, согласно требованиям бизнес-модели.
Настройка предметной части КИС зависит от профиля деятельности предприятия, включая, например, программное обеспечение для финансового анализа, складскую программу либо PDM-систему. Некоторая часть КИС определяется такими характеристиками, как масштаб организации, величина и сложность информационных потоков.
С их увеличением становится актуальным внедрение специализированных модулей делопроизводства и архивного хранения, которые способны поддерживать крупные электронные архивы смешанной документации с обеспечением необходимого уровня надежности и безопасности хранения информации. Тем самым, определяется функциональная модель КИС (функционал КИС).
В дополнение к функционалу, структуру КИС определяют и реализующие данный функционал технологии. С этой точки зрения современные информационные системы должны отвечать целому набору обязательных требований.
Например, использование архитектуры клиент-сервер с возможностью применения большинства промышленных СУБД, обеспечение безопасности с помощью различных методов контроля и разграничения доступа к информационным ресурсам, поддержку распределенной обработки информации, модульный принцип построения из оперативнонезависимых функциональных блоков с расширением за счет открытых стандартов (API, COM и другие), а также поддержку технологий Intemet/intranet.
Кроме того, немаловажную роль играют и другие, эксплуатационные характеристики: легкость администрирования, эргономичность, наличие локализованного (русифицированного) интерфейса.
- Процедуры управления настройкой и адаптацией обычно описываются в плане, либо в нем указывается ссылка на отдельный документ, который рассматривается как стандарт управления настройкой и адаптацией.
- Управление тестированием (стабилизацией). Обычно тестирование бывает двух категорий: функциональное и пользовательское. Целью функционального тестирования является максимально полная проверка каждого программного модуля на предмет сбоев.
Для этой категории разрабатываются специальные типы тестов. Пользовательское тестирование - это следующий уровень тестирования, который выполняется, когда формальные контрольные примеры уже практически не выявляют ошибок.
В этом случае, продукт тестируется путем имитации действий различных групп пользователей.
- Управление рисками и качеством внедрения. Риск всегда является неотъемлемой составляющей любого сложного и ответственного процесса.
Более того, совершение рискованных действий необходимо для прогресса, а ошибки, как известно, являются основой приобретения опыта. Несмотря на то, что некоторые риски неизбежны, это не означает, что попытки определить их и управлять ими вредят творческой работе.
Процедурное управление рисками на всем протяжении проекта является одним из самых главных факторов успеха.
Обеспечение качества готового продукта (версии) достигается нахождением оптимального баланса между тремя составляющими: функциональность, надежность, дата выпуска. Каждая из этих составляющих формируется на основе ожиданий заказчика. Очевидно, что не каждый проект является критичным к дате выпуска, так же как не каждый проект критичен к полноте реализации функциональности.
Некоторые ошибки можно легко обойти путем изменения сценария действий пользователя, так как часто сохранение запланированного срока ввода продукта в эксплуатацию оказывается важнее, чем задержка из-за исправления ошибок и выполнения повторного тестирования.
- Запуск КИС (версии) в опытную эксплуатацию.
- Разработка правил работы с КИС и утверждение процедуры внесения изменений в конфигурацию.
- Обучение и сертификация пользователей и администраторов.
- Организация работы подразделения технической и пользовательской поддержки.
Выбор ERP-системы для внедрения можно производить самостоятельно или привлечь для этого консультанта. Но в любом случае необходимо представлять, каким требованиям должна удовлетворять внедряемая система, чтобы вложенные инвестиции принесли максимальную прибыль.
Обычно выделяют следующие требования к КИС:
Охват всех основных процессов управления корпорацией. Выбирая систему, следует оценить ее функциональность с точки зрения полноты охвата принятых де-факто на предприятии бизнес-процессов.
В противном случае может быть нарушена непрерывность информационных потоков и целостность и непротиворечивость данных для принятия решений, что резко снизит ценность внедряемой системы.
Модульность. Функциональность поставляемой системы должна быть в меру избыточной.
Чтобы не тратить лишние деньги, но и иметь определенный запас быстрого наращивания функциональности, полезно иметь возможность выбрать необходимые модули и скомпоновать функциональное решение, отвечающее конкретному бизнесу. Такой подход позволит в перспективе легко наращивать функциональность системы, как добавляя и настраивая необходимые новые компоненты, так и используя избыточную резервную функциональность имеющихся.
Многозвенная архитектура клиент-сервер. Архитектура решения должна обеспечивать формирование и поддержку единой базы данных и подключение к ней необходимого числа пользователей, в том числе, через Веб-броузер - это позволяет использовать функции системы с любого рабочего места локальной сети компании и удаленно.
Адаптируемость. Система должна отвечать специфике бизнеса конкретного предприятия, иметь возможность удобной настройки форм документов, структур данных и схем процессов для решения бизнес задач.
Интеграция с электронными каналами. Корпоративная система должна предусматривать интеграцию с модулями электронной коммерции и электронного взаимодействия с серверами партнеров и бизнес сообществ.
Региональная и отраслевая специализация. Система должна быть локализована для определенного географического региона (язык, валюта, формат дат и т.п.), использовать методики учета и формы документов, регламентированных региональными и отраслевыми нормативными актами.
Желательно, чтобы система дополнительно содержала встроенные отраслевые справочники и поддерживала процессы, характерные для конкретного бизнеса.
Удобный экранный интерфейс. Необходимо применять удобные в использовании, привычные и очевидные экранные интерфейсы, чтобы сократить время обучения пользователей, уменьшить количество ошибок, повысить производительность работы и доверие к новому инструментарию.
Информационная открытость. Используемое решение должно учитывать необходимость интеграции со смежными корпоративными системами и информационными системами подразделений, партнеров и бизнес сообществ, обеспечивать возможность перспективного развития/реорганизации ИС.
Для этого внедряемая корпоративная система должна обладать средствами доступа к внутренним функциям (API), программирования и настройки, использовать основные стандартные протоколы передачи данных.
Консолидация данных. В случае холдинговой организации компании корпоративная система управления должна иметь средства формирования и анализа консолидированных данных по нескольким бизнес единицам, входящим в холдинг.
Безопасность и надежность. Должны быть реализованы средства разграничения доступа пользователей к функциям и данным (на основе настраиваемых администратором ролей и прав), предусмотрены средства защиты от несанкционированного доступа к информации в зависимости от требований конфиденциальности, должны быть реализованы меры по обеспечению достоверности и целостности данных и защиты их от разрушения.
В качестве ядра всего информационного комплекса системы автоматизации выступают так называемые функциональные, процессные и информационные модели. Это наиболее органичный и эффективный способ построения КИС, при котором выполняются вышеперечисленные функции и требования к технологичности. Деятельность любой организации представляет собой совокупность выработанных в повседневной практике бизнес процессов, в которые вовлечены финансовые, материальные, кадровые, информационные и прочие виды ресурсов.
Именно бизнес процессы определяют порядок взаимодействия отдельных сотрудников и целых отделов, а также принципы построения информационных систем. Поэтому автоматизация предприятия, исходя из бизнес процесса, наиболее логична.
В качестве инструмента разработки подобных моделей и их интеграции широко используются, в частности, современные workflow-системы, выступающие в роли связующего звена, вокруг которого и объединяются другие программные продукты. В результате настройки структуры КИС с использованием подобных инструментов можно автоматизировать деятельность предприятия практически любой отрасли и при этом сохранить специфические, критически важные нюансы управленческого и организационного ноу-хау. Кроме того, в этом случае автоматизацию не нужно начинать с нуля.
Интегрированный комплекс может создаваться на базе разрозненных автоматизированных рабочих мест, то есть с использованием уже имеющегося системного и прикладного программного обеспечения. При применении современных workflow-систем, которые характеризуются открытостью и широкими возможностями по настройке, легко достигается динамичная и гибкая модификация целей и функций КИС.
Технология моделирования КИС может использовать различные нотации для описания процессов, функций, информационных потоков и т.д. Например:
- Функциональную модель IDEF0;
- Модель процессов IDEF3;
- Информационную модель IDEF1X.
- Онтологическая модель IDEF5 и т.д.
Для эффективного управления проектом создания (внедрения) КИС требуется детализованное описание и документирование всех его этапов. Особенно важным представляется наличие описания проекта, независимое от конкретной технологии реализации, так как возможны ее изменения, использование нескольких технологий одновременно. Таким описанием и является функциональная модель IDEF0:
- методология функционального моделирования;
- создание reference model''-основы для дальнейшей работы;
- реинжиниринг бизнес-процессов, модификация деловых процедур и т.д.
Модель в виде IDEF0 технологически независима и дает возможность провести анализ спектра возможных реализаций в терминах прикладной системы.
Информационная модель IDEF1X:
- методология информационного моделирования;
- описание структур данных;
- проектирование баз данных и т.д.
Данная методология хорошо известна (еще и как ER-диаграммы).
Модель процессов IDEF3:
- методология моделирования процессов;
- проектирование процедур;
- описание технологических карт и т.д.
Модель в виде IDEF3 оптимальна для чернового моделирования и представления технологических карт (должностных инструкций).
Онтологическая модель IDEF5:
- Изучение и систематизирование начальных условий. Это действие устанавливает основные цели и контексты проекта разработки онтологии, а также распределяет роли между членами проекта
- Сбор и накапливание данных. На этом этапе происходит сбор и накапливание необходимых начальных данных для построения онтологии.
- Анализ данных. Эта стадия заключается в анализе и группировке собранных данных и предназначена для облегчения построения терминологии.
- Начальное развитие онтологии. На этом этапе формируется предварительная онтология, на основе отобранных данных.
- Уточнение и утверждение онтологии - заключительная стадия процесса.
Онтологический анализ обычно начинается с составления словаря терминов, который используется при обсуждении и исследовании характеристик объектов и процессов, составляющих рассматриваемую систему, а также создания системы точных определений этих терминов. Кроме того, документируются основные логические взаимосвязи между соответствующими введенным терминам понятиями.
Результатом этого анализа является онтология системы, или же совокупность словаря терминов, точных их определений взаимосвязей между ними.
К сожалению, на практике приходится сталкиваться с недостаточным уровнем понимания и проработки моделей будущей КИС. Как правило, не только не реализуется полный цикл разработки, но даже часто и не планируется. Наиболее существенными причинами такой ситуации являются следующие:
- длительность (задача ставится в последний момент);
- отсутствие квалифицированных специалистов (особенно менеджеров и системных аналитиков);
- отсутствие интегрированных средств поддержки полного жизненного цикла системы;
- теоретически высокая стоимость;
- вводящая в заблуждение реклама;
- плохая постановка перспективного планирования
- отсутствие формальных критериев или их качественный характер оценки будущей КИС.
Построение современной КИС, как правило, процесс длительный. На практике он длится более одного года. Естественно, нужно уметь распределить силы и средства на весь период, что непривычно и необычно для отечественных менеджеров.
Нужно уметь направить первый удар в ключевые области, а они то и неизвестны.
Как выбрать систему под конкретный объект? В основе должна быть четкая постановка задачи, то есть должно быть известно, какие бизнес процессы предполагается автоматизировать, какие предъявляются системотехнические требования и тому подобное.
За основу можно взять следующие принципы классификации:
- Количество функциональных подсистем;
- Качество (уровень) взаимосвязи между подсистемами;
- Опция конкретного клиента (например, аппаратная платформа).
Анализ КИС. Процесс анализа представляет собой анализ проблемы, которую организация пытается решить путем построения КИС.
Суть анализа состоит в определении проблемы, выявлении ее причин, определении решения и потребностей в информации, которым оно должно удовлетворять.
Системным аналитиком создается карта существующих в организации систем и их взаимодействия, на которой видны поставщики и потребители той или иной информации. Эти стороны напрямую заинтересованы в получении информации, которая будет представляться новой системой.
Также в задачи системного аналитика входит описание наличного в организации программного обеспечения и аппаратных средств.
