Введение

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

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

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

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

В нашем случае мы имеем дело с принципиально иным способом работы с конструкторской и технологической информацией. Система TechnologiCS (а в дальнейшем речь пойдет именно о ней) представляет собой прежде всего централизованное хранилище информации об изделиях (базу данных). С этой точки зрения она очень похожа на традиционные системы управления предприятием (АСУП). Тем не менее есть и существенное отличие, позволяющее преодолеть традиционный изъян подобных систем — недостаточную актуальность данных и часто возникающую необходимость в повторном вводе информации. TechnologiCS (www.technologics.ru) предоставляет владельцам информации — конструкторам и технологам — возможность непосредственной работы с базой данных. При этом доступ к базе осуществляется через удобный интерфейс, в каждом конкретном случае ориентированный на выполнение определенной функции (аналогично АРМ); предусмотрены и все необходимые средства автоматизации для решения инженерных задач.

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

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

Процессный подход

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

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

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

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

Функциональное и процессное внедрение ИС

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

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

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

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

Говоря о процессном внедрении, нельзя не упомянуть об инструментарии, применяемом для моделирования бизнес-процессов. Сам по себе процессный подход не предъявляет особых требований к инструментам описания и проектирования бизнес-процессов, однако использование специализированных инструментов вместо стандартных офисных программ имеет массу неоспоримых преимуществ. Среди множества представленных на рынке инструментальных средств, пожалуй, наиболее эффективным следует признать программный продукт ARIS (этот вывод подтверждается результатами исследований, опубликованными Gartner Group в январе 2004 года). ARIS (Architecture of integrated Information Systems — архитектура интегрированных информационных систем) представляет собой методологию и базирующееся на ней семейство программных продуктов, разработанных компанией IDS Scheer. Чтобы дать некоторое представление об ARIS, перечислим ее основные преимущества:

Представление бизнес-процессов в виде графических моделей;

Наличие единого стандарта моделирования;

Ориентация на процессный подход;

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

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

Возможность организации совместной работы в сетях Интернет и интранет.

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

Информационная система и процессный подход

Рассмотрим несколько типичных случаев автоматизации на производственном предприятии.

1. Отсутствие автоматизации .

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

Основной носитель информации в этом случае — документ, обработка информации носит последовательный характер.

2. На предприятии действует автоматизированная система управления (АСУП) .

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

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

3. Различные варианты использования локальных средств автоматизации .

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

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

Что же дает внедрение системы TechnologiCS в плане применения процессного подхода и совершенствования бизнес-процессов?

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

Перечислим основные преимущества рассматриваемого способа работы — с точки зрения организации процессов на предприятии:

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

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

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

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

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

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

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

Опыт реальных проектов

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

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

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

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

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

Приведем пример из практики, обещанный в самом начале этой статьи. Подходы, преимущества которых мы постарались обосновать выше, использовались при подготовке проекта внедрения системы TechnologiCS для автоматизации процессов конструкторской и технологической подготовки производства на Новосибирском заводе химконцентратов. Работы были выполнены проектной группой, состоявшей из специалистов компании CSoft (www.csoft.ru), консультантов компании «Логика бизнеса» (www.ids-scheer.ru) и сотрудников предприятия.

Руководству предприятия не потребовалось доказывать преимущества процессного внедрения, тем более что незадолго до этого под руководством консультантов компании «Логика бизнеса» на заводе был выполнен пилотный проект по описанию и совершенствованию бизнес-процессов планирования. Предприятие проявило высокую готовность к изменениям бизнес-процессов в заявленной предметной области, а детальное знакомство с возможностями TechnologiCS убедило заказчика в принципиальной применимости процессного подхода — сквозной автоматизации процессов конструкторской и технологической подготовки производства.

В общем случае проект процессного внедрения информационной системы включает следующие этапы:

Подготовка проекта;

Концептуальное проектирование;

Реализация;

Заключительная подготовка;

Ввод в эксплуатацию и поддержка.

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

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

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

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

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

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

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

Подготовка проекта

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

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

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

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

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

Концептуальное проектирование

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

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

Результатом работы на этом этапе стало появление детально проработанного документа «План перехода к процессам “как должно быть”» (рис. 5).

Краткие выводы

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

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

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

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

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

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

Формализованное описание целевой ситуации, формирующейся в результате внедрения;

Обоснованный объем финансовых ресурсов, необходимых для приобретения лицензий программного обеспечения;

Обоснованный объем трудозатрат, необходимый для осуществления всего проекта; сроки проведения этих работ;

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

Обоснованный объем внутренних трудовых ресурсов, занятых в рамках проекта.

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

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

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

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

Критически важными для внедрения являются следующие факторы :

· наличие четко сформулированных целей проекта и требований к ИС;

· наличие стратегии внедрения и использования ИС;

· проведение предпроектного обследования предприятия и построения моделей "Как есть" и "Как будет";

· планирование работ, ресурсов и контроль выполнения плана внедрения;

· участие высшего руководства во внедрении системы;

· проведение работ по внедрению ИС специалистами по интегрированию систем совместно со специалистами предприятия;

· регулярный мониторинг качества выполняемых работ;

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

Перед началом разработки проекта внедрения необходимо:

· максимально формализовать цели проекта внедрения ИС;

· оценить минимально необходимые затраты и статьи расхода;

· установить высокий приоритет проекта внедрения перед остальными текущими проектами;

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

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

· разработать организационные меры для применения новых информационных технологий;

· распределить персональную ответственность по всем этапам внедрения и опытной эксплуатации.

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

· организационное управление;

· организационно-административное обеспечение;

· управление бизнес-процессами;

· управленческий, планово-финансовый и бухгалтерский учет;

· управление персоналом;

· управление документацией;

· управление материально-техническим обеспечением;

· управление связями с клиентами и внешней средой.

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

· системная платформа - внедрение и адаптация готового решения от производителя или разработка на заказ в соответствии с техническим заданием заказчика;

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

· адаптируемость - система настраивается в соответствии с требованиями заказчика и на особенности информационного поля заказчика;

· распределенность - система может эффективно функционировать в территориально удаленных подразделениях и филиалах предприятия;

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

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

Фаза "Предварительные работы по подготовке проекта внедрения ИС" . В ходе предпроектного обследования предприятия (рис. 4) происходит сбор подробной информации о структурном построении организации, функциональных связях, системе управления, об основных бизнес-процессах, о потоках внутри предприятия (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), необходимой для построения соответствующих моделей и выбора объектов для автоматизации. Оцениваются сроки, ресурсы, виды и объемы работ, номенклатура и стоимость программно-аппаратных и телекоммуникационных средств, стоимость обучения персонала и т. д.

Фаза "Подготовка проекта" . После завершения первой фазы осуществляется предварительное планирование и формирование процедур запуска проекта:

· формирование проектной и экспертной групп;

· распределение полномочий и ответственности;

· определение организационно-технических требований к процессу внедрения;

· уточнение спецификаций и ожиданий заказчика;

· обучение группы внедрения, состоящей из специалистов предприятия-заказчика.

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

Фаза "Концептуальная проработка проекта" . В течение этой фазы:

· формируется и утверждается концептуальный проект;

· уточняются и конкретизируются цели и задачи проекта;

· определяются размеры прототипа системы;

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

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

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

Рисунок 12 - Примерное содержание репозитория проекта внедрения

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

Рисунок 13 - Примерный состав документации по процессу внедрения информационной системы

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

После окончания фазы реализации проект внедрения считается законченным. Информационная система передается в эксплуатацию.

Контрольные вопросы

1. Что такое "открытая информационная система"? Перечислите основные свойства открытых систем.

2. Охарактеризуйте суть современного процессного подхода к управлению деятельностью предприятия и использования этого подхода при разработке ИС.

3. Какие модели и каким образом используются при проектировании информационных систем?

4. Какие программные средства используются для моделирования процессов при разработке информационных систем?

5. На основании каких данных и информации разрабатываются модели состояния AS IS и AS TO BE?

6. Кто в компании занимается вопросами разработки, внедрения и развития ИС? Кто участвует в подготовке технического задания на разработку ИС?

7. Назовите основные этапы проектирования информационных технологий.

8. Перечислите этапы жизненного цикла информационной системы.

9. На каком этапе разработки и внедрения ИС производится обучение персонала компании?

10. Перечислите основные фазы внедрения ИС.

Подробности Опубликовано: 14.07.2018 21:24 : рассматриваются базовые этапы внедрения корпоративных информационных систем. Кроме того выполняется обзор проектных документов каждого из этапов, а также демонстрируется зависимость данных заданной фазы на документы последующих этапов.
Скачать: PDF .
Ключевые слова: документы ERP систем, документирование внедрения корпоративных информационных систем, документирование информационных систем, документы в информационной системе, проектная документация ERP систем, рабочая документация ИС, техническая документация КИС, нормативные документы информационной системы, нормативные документы по проектированию информационных систем, документы внедрения ПО, документы внедрения информационных систем, этапы и документы внедрения программного продукта, опытная эксплуатация информационных систем, ГОСТ Р 54869-2011, ANSI PMBoK.

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

Цель и задачи

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

• обзор литературы, посвященной внедрению КИС;
• рассмотрение базовых этапов имплементации КИС;
• анализ проектных документов и их зависимостей от этапов.

1. Обзор подходов внедрения корпоративных информационных систем

Корпоративная информационная система представляется совокупностью информационных систем (далее - ИС), определяющих заданную предметную область. Существует несколько подходов внедрения ИС, применимых так же для имплементации КИС (рис.1). Начнем обзор с подхода, декларированного государством. Речь идет об отраслевых стандартах, в частности, ГОСТ Р 54869-2011 , а так же международном стандарте ISO 21500 . Документы содержат описание этапов управления проектами от процесса инициализации до завершения вне зависимости от вида реализуемой системы. Поэтому возможно использование указанных стандартов для реализации технических, информационных и корпоративных систем. Свод профессиональных знаний по управлению проектами, представленный ANSI PMI PMBoK , регламентирует процессы планирования, исполнения, проверки и воздействия от этапа инициирования до завершения проекта. Аналогично ГОСТ Р 54869-2011 и ISO 21500 допускается его применение для управления внедрением различных видов систем.

Рис. 1.

Методологии Accelerated SAP (далее - ASAP) , Accenture Delivery Methods (далее - ADM) , а также Microsoft Dynamics Sure Step (далее - MDSS) используются компаниями SAP, Accenture и Microsoft соответственно при внедрении пакетированных КИС решений. Подходы ориентированы исключительно на реализацию проектов имплементации КИС. В рассмотренных выше подходах используется преимущественно каскадная схема внедрения КИС . Данная схема характеризуется строгой временной зависимостью выполнения этапов проекта. Работы на заданном этапе могут выполняться только в том случае, если реализованы все активности предыдущей фазы проекта. Наименование этапов разнится от подхода к подходу, однако, содержание работ неизменно. Поэтому вполне реально сформировать единый перечень как операций, так и подготавливаемых документов. Подытожим результат анализа подходов внедрения КИС списком типовых этапов реализации проекта (рис.2).

Рис. 2.

2. Проектные документы типовых этапов реализации проекта

В предыдущем разделе были выделены типовые этапы реализации проектов по внедрению КИС, включающие

• подготовку проекта;
• проектирование;
• реализацию;
• подготовку к опытно-промышленной эксплуатации (далее - ОПЭ);
• ОПЭ;
• переход к продуктивной эксплуатации (далее - ПЭ)

и являющиеся общими для методологий ASAP, ADM, MDSS и стандартов . Допускается отсутствие этапа ОПЭ, тогда 4-я и 5-я фазы проекта будут обеспечивать подготовку к ПЭ и ПЭ соответственно. Рассмотрим документы каждого из этапов подробнее (рис.3).

Рис. 3.

2.1. Этап подготовки проекта

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

2.2. Этап проектирования

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

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

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

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

2.3. Этап реализации

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

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

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

2.4. Этап подготовки к опытно-промышленной эксплуатации

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

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

2.5. Этап опытно-промышленной эксплуатации

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

2.6. Этап перехода к продуктивной эксплуатации

Успешное завершение этапа ОПЭ позволяет говорить о переходе к ПЭ. Основное условие перехода – отсутствие замечаний в журнале проблем и обновление всей проектной документации по результатам исправления замечаний. Аналогично этапу подготовки к ОПЭ готовятся списки пользователей системы, планы перехода к ПЭ и миграции данных. Заполняются шаблоны загрузок данных. Создав пользователей в КИС, выполнив все операции из плана перехода и миграцию данных, начинается работа в режиме ПЭ. Начиная с этого момента, возникающие замечания и проблемы разрешаются силами группы поддержки клиента. На этапах же реализации, подготовки к ОПЭ и ОПЭ ошибки системы регистрировались в журнале проблем и исправлялись специалистами подрядчика.

3. Зависимость подготавливаемых документов от этапов проекта

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

Рис. 4.

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

Результаты и выводы

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

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

Литература

1. ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом. – М.: Стандартинформ, 2011. – 10 с.
2. Zandhuis A., Stellingwerf R. ISO 21500. Guidance on Project Management. A pocket guide. – NL.: Van Haren Publishing, 2013. – 148 p.
3. ANSI/PMI 99-001-2014. A Guide to the Project Management Body of Knowledge (PMBOK Guide). – Pennsylvan.: Project Management Institute, 2013 – 589 p.
4. Brand H. SAP R/3 Implementation With ASAP: The Official SAP Guide. – NJ.: Sybex Inc, 1999. – 591 p.
5. Kress R. Running IT Like a Business: A Step-By-Step Guide to Accenture"s Internal IT. – Ely: IT Governance Publishing, 2012. – 140 p.
6. Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. – Birmingham: Packt Publishing, 2011. – 360 p.
7. Проектирование информационных систем: учебное пособие / Гвоздева Т.В., Баллод Б.А. – Ростов н/Д.: Феникс, 2009. – 508 с.
8. Ковалев С., Ковалев В. Секреты успешных предприятий: бизнес-процессы и организационная структура. – М.: БИТЕК, 2012. – 498 с.
9. Степанов Д.Ю. Обзор логистических бизнес-процессов на примере закупочной деятельности предприятия // Логистика сегодня. – 2014. – т.65, №5. – c.208-228.
10. Степанов Д.Ю. Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку // Актуальные проблемы современной науки. – 2014. – т.78, №4. – c.258-268.

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

Фаза «Предварительные работы по подготовке проекта внедрения ИС». В ходе предпроектного обследования предприятия происходит сбор подробной информации о структурном построении организации, функциональных связях, системе управления, об основных бизнес-процессах, о потоках внутри предприятия (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), необходимой для построения соответствующих моделей и выбора объектов для автоматизации. Оцениваются сроки, ресурсы, виды и объемы работ, номенклатура и стоимость программно-аппаратных и телекоммуникационных средств, стоимость обучения персонала и т. д.

Фаза «Подготовка проекта». После завершения первой фазы осуществляется предварительное планирование и формирование процедур запуска проекта:

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

Фаза «Концептуальная проработка проекта». В течение этой фазы:

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

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

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

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

Рис. 2.17. Примерное содержание репозитория проекта внедрения

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

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

Рис. 2.18. Примерный состав документации по процессу внедрения ИС

После окончания фазы реализации проект внедрения считается законченным. Информационная система передается в эксплуатацию.

Контрольные вопросы и задания

1. Что такое "открытая информационная система"?
2. Перечислите основные свойства открытых систем.
3. Охарактеризуйте суть современного процессного подхода к управлению деятельностью предприятия и использования этого подхода при разработке ИС.
4. Что включает в себя понятие "Реинжиниринг бизнес-процессов"?
5. Какие модели и каким образом используются при проектировании информационных систем?
6. Какие программные средства используются для моделирования процессов при разработке информационных систем?
7. На основании каких данных и информации разрабатываются модели состояния AS IS и AS TO BE?
8. Кто в компании занимается вопросами разработки, внедрения и развития ИС? Кто участвует в подготовке технического задания на разработку ИС?
9. Назовите основные этапы проектирования информационных технологий.
10. Перечислите этапы жизненного цикла информационной системы.
11. На каком этапе разработки и внедрения ИС производится обучение персонала компании?
12. Перечислите основные фазы внедрения ИС.

Глава 3. Программные средства компьютерных информационных технологий

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

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

Вопросы разработки и использования программного обеспече­ния вообще достаточно хорошо проработаны и широко освещены в научной и учебно-практической литературе. Но необходимы некоторые уточнения.

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

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

В составе программного обеспечения выделяются (рис. 3.1):

Системное программное обеспечение;

Инструментальное обеспечение разработки программ;

Прикладное программное обеспечение.

Рис.3 .1. Структура программного обеспечения информационных технологий

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

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

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

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

3.2. Жизненный цикл программных средств компьютерных информационных технологий

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

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

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

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

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

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

· приобретение промышленного программного продукта, его модернизация или разработка уникального программного продукта;

· установка программного продукта на имеющуюся вычислительную систему офиса;

· эксплуатация программного продукта;

· оценка эффективности применения программного продукта;

· модернизация программного продукта;

· демонтаж программного продукта.

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

Выбор конкретного программного продукта должен осуществляться на основе совместного рассмотрения следующих факторов:

· наличие промышленных программных продуктов, реализующих функции конкретной информационной технологии;

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

3.3. Сущность и основные понятия систем управления базами данных

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

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

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

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

· имеются определенные методы поиска и извлечения (выборки) необходимой информации и ее представления.

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

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

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

Рассмотрим пример. Данные о сотрудниках некоторой проектной организации включают в себя:

· табельный номер сотрудника;

· фамилию, имя и отчество;

· дату рождения;

· домашний адрес;

· домашний телефон;

· дату поступления на работу;

· место работы;

· служебный телефон;

· должность;

· надбавку за стаж работы;

· проект, в котором участвует сотрудник;

· надбавку за участие в проекте.

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

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

Таблица представляет собой лишь небольшой фрагмент БД, но его свойства весьма показательны.

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

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

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

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

Описанные действия по представлению данных в теории и практике создания БД называют нормализацией.

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

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

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

Представленное в описанном примере структурирование и упорядочивание данных в целом характерно для всех систем управления БД и для различных программ отличается в деталях.

3.4. Компьютерные системы управления базами данных

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

К наиболее популярным СУБД для вычислительных систем класса персональных компьютеров относятся dBASE IV, Microsoft Access, FoxPro, Paradox. Для более мощных систем предназначены СУБД Oracle, Informix. В определенной степени возможности управления данными имеются и у большинства современных табличных процессоров.

По степени универсальности различают два класса СУБД:

· системы общего назначения;

· специализированные системы.

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

Специализированные СУБД создаются в редких случаях при невозможности или нецелесообразности использования СУБД общего назначения.

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

Рассмотрим основные характеристики некоторых СУБД – лидеров на рынке программ, предназначенных как для разработчиков информационных систем, так и для конечных пользователей.

Нет ничего труднее, опаснее и неопределённее, чем руководить введением нового порядка вещей, потому что у каждого нововведения есть ярые враги, которым хорошо жилось по старому, и вялые сторонники, которые не уверены, смогут ли они жить по новому.
Н. Макиавелли

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

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

1. Развертывание системы на площадке опытной эксплуатации

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

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

Рисунок 19. – Пример технического описания этапа внедрения

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

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

Между тем 90% времени уже пролетело…

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

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

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

А мы на этапе проектирования предупреждали, что обучение персонала заказчика не только очень ответственная задача, но еще и очень трудоемкая…

3. Выявление недостатков и дефектов информационной системы

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

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

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

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

А тем временем мы достигли дна, отведенного для проекта времени…

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

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

Этап согласования нового решения очень важен, как минимум по двум причинам.

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

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

И вот перефразируя Ежи Леца: «Когда мы достигли дна отведенного времени, снизу постучались...»

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

5. Доработка информационной системы по итогам опытной эксплуатации

Если в ходе опытной эксплуатации принимаются и согласуются решения о внесении изменений в разработанный программно-аппаратный комплекс, то на основании их выставляются задачи исполнителям по их реализации. Процесс, описанный в разделе Часть 3. Реализация проектного решения повторяется. Но…

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

Собственно говоря, наступил момент, когда актуальны следующие условия:

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

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

Рисунок 20. – Этап внедрения информационной системы

Без комментариев…

6. Передача информационной системы в промышленную эксплуатацию

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

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

7. Резюме раздела

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

1. Развертывание системы на площадке промышленной эксплуатации, включая поставку оборудования, установку системного ПО, установку актуального релиза внедряемой системы и т.п.;
2. Обучение пользователей работе с системой, включая администраторов, специалистов по обслуживанию оборудования и т.п.
3. Выявление и устранение недостатков и дефектов, выявленных в ходе опытной эксплуатации.
4. Согласование изменений в работе системы и приведение ее к соответствию контрактным обязательствам;
5. Подписание документов о выполнении договорных обязательств. Произведение полного расчета за выполненные работы;
6. Ввод системы в промышленную эксплуатацию;