интересно
Предыдущая | Содержание | Следующая

Управление проектом построения и развития КИС

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

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

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

Управление настройкой и адаптацией программного обеспечения, согласно требованиям бизнес-модели .

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

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

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

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

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

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

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

Запуск КИС (версии) в опытную эксплуатацию.

Разработка правил работы с КИС и утверждение процедуры внесения изменений в конфигурацию.

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

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

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

Обычно выделяют следующие требования к КИС:

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

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

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

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

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

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

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

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

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

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

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

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

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

Функциональную модель IDEF0;

Модель процессов IDEF3;

Информационную модель IDEF1X.

Онтологическая модель IDEF5 и т.д.

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

методология функционального моделирования;

создание "reference model-основы для дальнейшей работы;

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

Модель в виде IDEF0 "технологически" независима и дает возможность провести анализ "спектра" возможных реализаций" в терминах прикладной системы".

Информационная модель IDEF1X:

методология информационного моделирования;

описание структур данных;

проектирование баз данных и т.д.

Данная методология хорошо известна (еще и как ER-диаграммы).

Модель процессов IDEF3:

методология моделирования процессов;

проектирование процедур;

описание технологических карт и т.д.

Модель в виде IDEF3 оптимальна для "чернового" моделирования и представления технологических карт (должностных инструкций).

Онтологическая модель IDEF5:

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

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

Анализ данных. Эта стадия заключается в анализе и группировке собранных данных и предназначена для облегчения построения терминологии.

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

Уточнение и утверждение онтологии - заключительная стадия процесса.

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

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

длительность (задача ставится "в последний момент");

отсутствие квалифицированных специалистов (особенно менеджеров и системных аналитиков);

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

теоретически высокая стоимость;

вводящая в заблуждение реклама;

плохая постановка перспективного планирования

отсутствие формальных критериев или их качественный характер оценки будущей КИС.

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

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

За основу можно взять следующие принципы классификации:

Количество функциональных подсистем;

Качество (уровень) взаимосвязи между подсистемами;

Опция конкретного клиента (например, аппаратная платформа).

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

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

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

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

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

Экономическая выполнимость: превысят ли результаты от внедрения новой системы затраты на ее создание?

Эксплуатация системы: впишется ли предлагаемое решение в рамки существующей управленческой и организационной структуры?

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

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

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

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

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

"куб предложения",

"точка выбора",

"куб возможностей",

что графически представляется следующим образом:

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

Кроме того, для получения обоснованного решения задачи анализа по вышеуказанной схеме:

• нужно "просмотреть" перспективу развития бизнес процессов, по крайней мере, на два года вперед;

многие бизнес технологии в российских фирмах находятся в стадии формирования, или быстро меняются;

часто происходят организационные изменения (например, слияния - разъединения);

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

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

Типичные узкие места программного обеспечения:

Низкий уровень функциональности, интегрированности и недостаточное количество настроек.

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

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

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

Несоблюдение принципа версионности .

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

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