Теория корпоративных информационных систем и ее уточнение

Подробности

Опубликовано: 20.10.2022 09:00

Автор: Степанов Дмитрий Юрьевич

Просмотров: 1495

Аннотация: в статье ведется уточнение теории корпоративных информационных систем для параметра управления ERP-проектом. Вводятся типовые проектные риски, которые должны быть учтены в стратегии управления проектом внедрения ERP-системы: игнорирование плана проекта заказчиком, непрекращающийся поток изменений объема проекта, низкая вовлеченность/недоступность сотрудников заказчика, низкая мотивация заказчика, завышенные ожидания от проекта у заказчика, а также частичная недоступность ресурсов исполнителя, отставание от план-графика исполнителем, недостаточная квалификация сотрудников исполнителя. Даются рекомендации по тому, как обрабатывать и в каких документах вести управление указанными рисками.
Скачать: PDF (статья), PDF (выпуск №20).
Ключевые слова: теория корпоративных информационных систем, снижение проектных рисков, затягивание сроков проекта, риск постоянных изменений, низкая вовлеченность сотрудников, управление ожиданиями проекта, план коммуникации, обработка запросов на изменение, согласование результатов проекта, подход к управлению рисками, RACI-матрица, лучшие практики PMBoK, PMBoK.

Введение

Несмотря на наличие большого числа конференций, книг, статей по теме информационных (далее – ИС) и корпоративных информационных систем (далее – КИС), вопрос их полноценного внедрения все-таки остается за скобками рассмотрения. Да, действительно, есть отличные монографии о проектировании КИС, однако они на 20-50% дублируют друг друга: даются общие фразы и классификации ИС, далее на протяжении половины книги описывают всевозможные графические нотации по проектированию бизнес-процессов [1-3]. Но достаточно ли этого для понимания порядка и хода внедрения КИС? Очевидно, что нет.

Среди множества книг о проектировании ИС хочется особенно выделить работу [4], в которой, несмотря на определенно теоретическую направленность материала, дается наиболее широкий набор методов построения архитектуры, выявления требований и моделирования процессов. Как ее дополнение можно рассмотреть книгу по идентификации бизнес-требований [5]. Однако и этого не всегда достаточно для построения полной картины имплементации КИС. Попытка упорядочить методы имплементации ERP-систем сделаны в работе [6], к которой позже были даны уточнения [7]. В рамках же этой статьи мы постараемся актуализировать весь перечень способов внедрения ERP-систем и КИС, используя и дополняя теорию корпоративных информационных систем [8].

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

1. Содержание стратегии управления проектом

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

В рамках теории КИС последовательно были описаны стратегии содержательной части и части, связанной с изменениями [8]. В то время как уровню управления проектом не было оказано должного внимания. Попытаемся исправить этот недочет. Стратегия управления проектом внедрения КИС должна минимизировать, исключать или передавать на откуп внешней стороне все проектные риски. Здесь сразу стоит уточнить, что преимущественно речь идет о рисках, связанных с заказчиком, так как на иные риски мы как исполнитель проекта можем повлиять. Какие же риски присущи проекту внедрения ERP, соотносимые с уровнем проекта? Если попытаться рассмотреть основные параметры проекта, а их всего 11-ть [10], то можно прийти к пониманию критичности трех из них, в частности:

Сроки = Содержание / Ресурсы.                                  (1).

Перефразируем (1), получаем следующую упрощенную форму:

      Когда = Что / Кто.                                            (2).

В разрезе каждого из параметров (2) попытаемся сформулировать проектные риски и способы реагирования на них. Таблица 1 содержит описание тех рисков, на обработку которых направлена стратегия управления проектом.

Табл. 1. Содержание стратегии управления проектом

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

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

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

Следующей проблемой, достойной выделение в отдельную главу в PMBoK, являются завышенные ожидания заказчика от исполнителя, проекта и продукта. Для того, чтобы вернуть заказчика с небес на землю, в работе [11] предлагается ряд мероприятий, позволяющих максимально вовлечь представителей заказчика в ход проекта. По задумке автора это обеспечит раннее знакомства пользователей с системой и более реалистичный взгляд на проект. Так, предлагается использовать силы заказчика для выявления требований, согласования проектных документов, работе с историческими данными в ходе миграции, тестирования системы и обучения оставшихся пользователей. Наиболее наглядным способом разграничения ответственности за выполнение задач является использование RACI матрицы, которая ведется в разрезе задач и документов проекта. Расшифровка RACI следующая: R – ответственный, A – подотчетный, C – консультируемый, I – информируемый. Для работ и задач индикаторы R и A могут быть присвоены только одному ответственному.

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

Риск отставания от плана-графика проекта на стороне исполнителя обычно обрабатывается следующим образом. Все проектные активности проходят через PDCA-цикл, т.е. сначала планируются, затем выполняются, далее контролируются и, наконец, корректируются из-за отставания. Обычно Р-активностям предшествует подэтап оценки предпосылок или реализуемости (Estimation – оценка), поэтому цикл иногда называют ePDCA. Основная ошибка проектного управления состоит в том, что руководители проекта упускают из внимания как подэтап оценки, так и этап предварительной корректировки отставаний. Выявление предпосылок критично для определения начальных дат выполнения задач, в то время как оценка отставаний и соответствующая корректировка плана обязательны для доставки результата в срок. Величина отставания, высчитываемая в человеко-днях, может быть подсчитана на основе программного продукта MS Project, позволяющего считать длительности работ от даты начала и наоборот. Распространённой практикой в высоко критичных проектах является применение принципов Agile, что позволяет демонстрировать полуготовый продукт заказчику для получения быстрой обратной связи. Причем под продуктом может пониматься как проектный документ, так и программное приложение.

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

Табл. 2. Документы стратегии управления проектом

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

Заключение

Объединение результатов проделанной работы и итогов статьи [8] позволяет актуализировать и поставить логическую точку в теории корпоративных информационных систем:

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

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

Литература

1. Петрова Е. А., Фокина Е. А. Информационный менеджмент. – М.: Лань, 2020. – 215 с.
2. Остроух А.В., Суркова Н.Е. Проектирование информационных систем. М.: Лань, 2019. – 164 с.
3. Калянов Г.Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. – М.: Горячая линия – Телеком, 2014. – 210 с.
4. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
5. Вигерс К., Битти Д. Разработка требований к программному обеспечению. – М.: БХВ, 2016. – 736 с.
6. Петров С.В. Стратегии реализации содержания в проектах внедрения ERP-систем // Корпоративные информационные системы. – 2018. – №4 – С. 61-68. – URL: https://corpinfosys.ru/archive/issue-4/137-2018-4-strategyimplementation.
7. Абазьева М.П. О стратегиях доставки содержания и изменений в проектах внедрения ERP-систем // Корпоративные информационные системы. – 2022. – №4 – С. 17-24. - URL: https://corpinfosys.ru/archive/issue-20/206-2022-20-contentchangestrategies.
8. Stepanov D.Yu. The theory of corporate information systems// Lecture Notes in Electrical Engineering, vol. 986. Springer, Cham. https://doi.org/10.1007/978-3-031-22311-2_3.
9. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: теория и практика // Российский технологический журнал. – 2015. – т.8, №3. – c.227-238. – URL: https://stepanovd.com/science/31-article-2015-2-erpthpr.
10. Ширенбек Х., Листер М., Кирмсе Ш. Руководство к своду знаний по управлению проектами. Руководство PMBoK. Шестое издание. – М.: Олимп-Бизнес, 2019. – 974 с.
11. Степанов Д.Ю. Управление ожиданиями в проектах имплементации ERP-систем // Корпоративные информационные системы. – 2018. – №3 – С. 46-52. – URL: https://corpinfosys.ru/archive/issue-3/142-2018-3-expectations.

Выходные данные статьи

Степанов Д.Ю. Теория корпоративных информационных систем и ее уточнение // Корпоративные информационные системы. – 2022. – №4 (20) – С. 7-16. – URL: https://corpinfosys.ru/archive/issue-20/205-2022-20-theorycis.

Об авторе

Степанов Дмитрий Юрьевич – кандидат технических наук, доцент МИРЭА, принимал участие более чем в 10 проектах внедрения корпоративных информационных систем на базе SAP, Microsoft и Sage. Специализируется на управлении материальными потоками, сбытом и системой документов. Автор более 25 статей, в том числе публикации в журналах «Логистика сегодня», «Вопросы экономических наук», «САПер» и др. Электронный адрес автора: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Статьи выпуска №20

1. Стратегии внедрения ERP-систем;
2. Теория корпоративных информационных систем и ее уточнение;
3. Стратегия доставки содержания и изменений в ERP-проектах;
4. Реализация концепции ролей и полномочий в SAP ERP;
5. Обзор российского ПО класса MES, ERP2 и BI (часть 1).