На стадии составления программы должны быть проработаны следующие процессы

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

Переход к продуктивной эксплуатации. Завершение проекта (фазы). Пример процедуры приемки результатов проекта. Пример процедуры согласования. Пример процедуры управления открытыми вопросами. Управление открытыми вопросами и проблемами осуществляется на двух уровнях.

Порядок работы с открытыми вопросами и проблемами уровня проекта в целом.

Детальное планирование стадии разработки и внедрения

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

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

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

Моделирование бизнес-процессов | Naked BPM

Для выполнения оценки работы персонала используют методики и процедуры, принятые компанией. Пример методики оценки персонала предложен В.Ильиным и изложен в книге «Руководство качеством проектов. Практический опыт » [13].

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

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

Подготовка инфраструктуры для фазы эксплуатации

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

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

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

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

Моделирование бизнес процессов: гайд от начала до конца

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

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

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

Осуществление итогов контроля качества проекта

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

К задачам этого этапа относится:

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

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

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

Управление рисками настройки и внедрения

Идентификация рисков данной стадии выполняется аналогично процессу идентификации рисков на предыдущих стадиях.

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

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

Управление рисками на данной стадии осуществляется аналогично процессу на предыдущих стадиях.

Подготовка персонала к завершению проекта

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

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

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

Организация тестирования

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

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

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

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

1. Верхний колонтитул:
2. заголовок тестового сценария;
3. описание тестового сценария;
4. цель выполнения данного тестового сценария;
5. затрагиваемая функциональная область, процесс, организационная единица и роль;
6. используемые системные транзакции;
7. ожидаемая продолжительность выполнения тестового сценария и целевая продолжительность выполнения сценария в реальных условиях.

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

• отметка о формальной приемке («да»/ «нет»);
• общие комментарии по исполнению сценария.

Реализация цикла тестирования

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

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

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

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

По ряду причин тестирование процессов следует реализовать отдельно.

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

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

Таблица 12.1. Шаблон документирования результатов процессного тестирования Роли Шаги процесса Организационные единицы

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

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

• применимо (роль принимает участие в процессе);
• не применимо (роль не принимает участие в процессе).

В центральном столбце производится перечисление подпроцессов/шагов тестируемого процесса.

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

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

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

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

Источник: intuit.ru

На стадии составления программы должны быть проработаны следующие процессы

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

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

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

1. Техническое задание
2. Эскизный проект
3. Технический проект
4. Рабочий проект
5. Внедрение

Если следовать этому стандарту, то на первом уровне ИСР должны находиться именно эти проектные продукты. Если бы пришлось разрабатывать АСУ для управления ядерным реактором или пилотируемым космическим аппаратом, то именно так и следовало поступать. Однако в коммерческой разработке ПО такой подход не эффективен.

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

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

При составлении базового плана работ не стоит стремиться максимально детализировать все работы. ИСР не должна содержать слишком много уровней, достаточно 3-5. Например, ИСР нашего проекта-примера разработки «Автоматизированной системы продажи документации» может выглядеть следующим образом (Рисунок 17).

1. Проект разработки «Автоматизированной системы продажи документации»
1.1. Подготовка технического задания на автоматизацию
1.1.1.1. Проведение аналитического обследования
1.1.1.2. Разработка функциональных требований
1.1.1.3. Разработка требований базовому ПО
1.1.1.4. Разработка требований к оборудованию и к операционно-системному ПО
1.1.1.5. Согласование и утверждение ТЗ
1.1.1.6. ТЗ утверждено
1.2. Поставка и монтаж оборудования
1.2.1.Разработка спецификации на оборудование 1.2.2.Закупка и поставка оборудования
1.2.3. Монтаж оборудования
1.2.4. Установка и настройка опреационно-системного ПО
1.2.5. Монтаж оборудования завершен
1.3. Поставка и установка базового ПО
1.3.1 .Разработка спецификаций на базовое ПО 1.3.2.Закупка базового ПО
1.3.3. Развертывание и настройка базового ПО
1.3.4. Базовое ПО установлено у заказчика
1.4. Разработка и тестирование прикладного ПО
1.4.1. Разработка спецификаций на прикладное ПО
1.4.2. Установка и конфигурирование рабочей среды
1.4.3. Проектирование и разработка ПО
1.4.3.1. Авторизация и аутентификация пользователей.
1.4.3.2. Разработка подсистемы заказа документации
1.4.3.2.1. Просмотр каталога продуктов.
1.4.3.2.2. Поиск продуктов по каталогу.
1.4.3.2.3. Заказ выбранных продуктов.
1.4.3.2.4. Просмотр информации о статусе заказа.
1.4.3.2.5. Информирование клиента об изменении статуса заказа.
1.4.3.2.6. Подсистема заказа документации передана в тестовую эксплуатацию (на серверах разработчика).
1.4.3.3. Разработка подсистемы обработки заказов
1.4.3.3.1. Просмотр и обработка заказов исполнителями из службы продаж.
1.4.3.3.2. Просмотр статистики поступления и обработки заказов за период.
1.4.3.3.3. Подсистема обработки заказов передана в тестовую эксплуатацию на оборудовании Заказчика
1.4.3.4. Разработка подсистемы сопровождения каталога 1.4.3.4.1. Подготовка и сопровождение каталога продукции.
1.4.3.5. Исправление ошибок
1.4.4. Тестирование ПО
1.4.4.1. Раунд 1
1.4.4.2. Раунд 2
1.4.4.3. Раунд 3
1.4.4.4. Выходное тестирование
1.4.5. Документирование прикладного ПО
1.5. Обучение пользователей
1.5.1 .Подготовка учебных курсов 1.5.2.Обучение сотрудников Отдела 123 1.5.3.Обучение руководства ОАО XYZ 1.5.4.Обучение администраторов системы
1.6. Ввод в опытную эксплуатацию
1.6.1. Развертывание и настройка прикладного ПО
1.6.2. Проведение приемо-сдаточных испытаний
1.6.3. Акт передачи системы в опытную эксплуатацию утвержден
1.7. Сопровождение системы в период опытной эксплуатации
1.8. Система передана в промышленную эксплуатацию

Рисунок 17. Иерархическая структура работ проекта разработки «Автоматизированной системы продажи документации» (курсивом выделены контрольные точки проекта)

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

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

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

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

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

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

Планирование организационной структуры

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

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

Планирование управления конфигурациями

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

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

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

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

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

Планирование управления качеством

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

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

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

• План управления рисками
• Оценку трудоемкости и сроков работ

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

Базовое расписание проекта

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

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

Базовое расписание это, как правило, элемент контракта с заказчиком. Контрольные точки (вехи) должны служить точками анализа состояния проекта и принятия решения «GO/NOT GO», поэтому они должны зримо демонстрировать статус проекта. Контрольная точка «Проектирование завершено» — плохо. Наиболее эффективный подход — метод последовательных поставок: контрольная точка «Завершено тестирование требований 1, 3, 5, 7»

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

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

Критический путь проекта (Critical path) — самая длинная цепочка работ в проекте. Увеличение длительности любой работы в этой цепочки приводит к увеличению длительности всего проекта.

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

Чтобы проиллюстрировать понятие критического пути рассмотрим пример «суперпроекта» 5 . Концепция проекта выглядит следующим образом.

Цель проекта. Сделать завтрак в постель

Результаты проекта. Завтрак в постели из вареного яйца, тоста и апельсинового сока.

Ресурсы. Имеется один оператор и обычное кухонное оборудование.

Сроки. Проект начинается на кухне в 8:00 и завершается в спальне.

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

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

Иерархическая структура работ, ориентированная на конечный продукт, с оценкой их длительности представлена на Рисунке 18.

Рисунок 18. Иерархическая структура работ «суперпроекта»

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

С учетом зависимостей мы получим следующую диаграмму расписания нашего проекта (Рисунок 19)

Рисунок 19. Диаграмма расписания «суперпроекта» с учетом зависимостей между работами.

В результате мы определили, что минимальный срок реализации нашего проекта составляет 10 минут. Однако мы не можем на этом остановиться, поскольку должны еще учесть ограничение по ресурсам. У нас только один оператор. Если мы посмотрим на диаграмму загруженности ресурсов (Рисунок 20), то увидим, что наш критический ресурс загружен на первой минуте на 400%. что недопустимо.

Рисунок 20. Диаграма загруженности ресурсов в «суперпроекте»

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

Рисунок 21. Критический путь в «суперпроекте»

Поэтому, после выравнивания ресурсов, расписание нашего проекта будет выглядеть следующим образом (Рисунок 22).

Рисунок 22. Расписание «суперпроекта» после выравнивания ресурсов

Теперь диаграмма загруженности ресурсов (Рисунок 23) выглядит приемлемо и у оператора даже появилось три минуты свободного времени на перекур. При этом общая длительность реализации проекта по-прежнему составляет 10 минут.

Рисунок 23. Диаграмма загруженности ресурсов после выравнивания

Выводы

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

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

Дополнительная литература и источники

1. «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е изд., PMI, 2004.

5 Интернет-источник идеи, к сожалению, восстановить не удалось.

Источник: citforum.ru

Проектирование управленческой информационной системы ERP-класса

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

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

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

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

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

2. Управленческий и регламентированный учёт

3. Поддержка документооборота

4. Планирование и прогнозирование

5. Поддержка бизнес-процессов

В начале 2000-х годов автор работал в оптово-розничной компании, использовавшей систему учёта товарно-материальных ценностей собственной разработки. К тому моменту в системе насчитывалось более 700 отчётов, в которых рассчитывались несколько десятков тысяч показателей. Поскольку практики описаний отчётов не было и разобраться в этом хаосе не представлялось возможным, каждый новый менеджер заказывал себе 10-15 новых отчётов, мобилизуя на эту работу программистов всеми доступными методами. Знакомая картина непозволительного расходования ресурсов?
Возникает вопрос: как на этапе проектирования ИС составить необходимый и достаточный список показателей, которые затем будут представлены в отчётах, предназначенных для принятия управленческих решений? Поскольку мы определились с тем, что ИС ERP должна стать инструментом СУ, ответ на этот вопрос очевиден: в ИС должны, в первую очередь, рассчитываться показатели, которые используются в СУ для управления деятельностью предприятия, подразделений, сотрудников. Показатели стратегического уровня управления разрабатываются на основе методики Balanced Scorecard (BSC), предназначенной для реализации стратегии предприятия. Таким образом, реализуя в ИС систему показателей BSC, мы обеспечиваем интеграцию ИС ERP и СУ на уровне стратегии. Подчинённые показатели выстраиваются методом декомпозиции стратегических показателей и составляют основу план-фактного управления предприятием.
Для решения задачи ИС, перечисленной в списке под номером 1, системы показателей недостаточно. Необходимо также предусмотреть сбор первичных данных, на основе которых эти показатели будут рассчитываться.

Решения о том кто, когда, по какому событию, при каких условиях регистрирует эти данные в информационной системе, должны быть зафиксированы в документах проекта ИС ERP: ролях пользователей, описаниях бизнес-процессов, регламентах бизнес-процессов, требованиях к функционалу. Не является также излишней проработка форматов отчётов, в которых показатели будут представлены. Если этот вопрос будет отдан на откуп программисту, заказчик может быть неприятно удивлён результатом в тот момент, когда обязательства внедренцев по этому вопросу будут уже выполнены. Активное участие заказчика в определении форматов является залогом получения результата в действительно «удобном для анализа виде».
Для того, чтобы система управления по показателям стала эффективным инструментом СУ, она должна быть проработана на процедурном уровне. Поэтому процедуры планирования показателей, сбора исходных данных, план-фактного анализа должны быть формализованы на этапе разработки бизнес-процессов предприятия.
Вообще говоря, задача ИС ERP, обозначенная выше под номером 2, является частным случаем задачи N 1. Управленческий и регламентированный учёт – это также процессы сбора первичных данных и представления информации для анализа сотрудниками компании и налоговыми органами, соответственно. Однако, на этапе управленческого консалтинга вопросы учёта необходимо рассмотреть отдельно, так как они должны найти специфическое отражение в проекте ИС.
В первую очередь, это касается описания юридической структуры предприятия и соответствующего документооборота. Зачастую, даже небольшие российские компании представляют из себя своего рода холдинги, объединяющие несколько юридических лиц, связанных коммерческими отношениями. Задача ИС заключается в формировании регламентной отчётности юридических лиц и управленческой отчётности холдинга с требуемой детализацией. В современных ИС класса ERP имеются развитые средства реализации юридических структур холдингов, но для настройки этих средств, структура и документооборот должны быть проанализированы и описаны на этапе формирования проекта. Таким образом будет достигнута интеграция ИС с организационной-правовым уровнем СУ предприятием.
Другой вопрос учёта, который должен быть проработан на этапе разработки проекта ИС — это учётная политика. Если учётная политика регламентированного учёта определяется действующим законодательством, то управленческая учётная политика разрабатывается самим предприятием и должна соответствовать его целям, стратегии, структуре управления. Управленческая учётная политика фиксируется в документе общепринятой структуры и является составной частью проекта ИС ERP.
В процессе проектирования будущей системы учёта должны быть также проработаны требования по безопасности и защите учётной информации.
Наконец, для обеспечения преемственности новой системы учёта с уже накопленной информацией, должны быть проработаны вопросы переноса справочников, остатков ТМЦ и денег, документов в новую ИС. Фактически, речь идёт об обеспечении непрерывности информационной поддержки системы управления предприятием.
Для обеспечения решения третьей из перечисленных задач ИС ERP, а именно поддержки документооборота, на этапе проектирования управленческой ИС должен быть проанализирован и структурирован документооборот компании. Обычно выделяют следующие подсистемы документооборота:
• Поддержка Юридической структуры
• Движение ТМЦ
• Обмен сообщениями, документами
• Формирование планов, задач. Отчётность по ним
• Создание, согласование, утверждение документов
• Регистрация и контроль исполнения входящих и исходящих
• Организация архива документов
В ходе проектирования управленческой ИС принимается решение о том, какие подсистемы документооборота будут поддерживаться ИС и формируется их описание, которое должно найти своё отражение в документах проекта информационной системы: графическом отображении бизнес-процессов, форматах структур данных, отчётах ИС, ролях пользователей, печатных формах. Таким образом, на этом этапе закладываются основы документарной поддержки СУ.
Учёт фактических данных в той или иной форме ведётся в компании всегда. А вот возможность полноценного решения четвёртой задачи ИС – планирования и прогнозирования, появляется только с момента внедрения ИС.
Планирование, как система целеполагания, является неотъемлемой частью системы управления предприятием. В ходе работ над проектом ИС ERP определяются состав планов, горизонты и периоды планирования, бизнес-процесс и средства ввода плановых значений, форматы план-фактных отчётов, бизнес-процессы план-фактного анализа и коррекции планов. Перечень планируемых показателей определяется списком, сформированным в ходе проектирования системы показателей. Особого внимания заслуживает система бюджетирования, которая является основой системы управления финансами. На этапе управленческого консалтинга проектирования ИС разрабатывается регламент бюджетирования, который включает в себя
• Описание финансовой структуры
• Форматы бюджетов
• Учётную политику
• Бизнес-процессы и правила их исполнения
Если планирование – это способ постановки целей, то прогнозирование – это формирование наиболее вероятного сценария развития событий на основе ранее собранной объективной информации. Современные ИС ERP-класса предоставляют широкие возможности для финансового прогнозирования, предназначенного для своевременного принятия эффективных решений в области оперативного управления финансами. В некоторых ИС реализован механизм номенклатурного прогнозирования продаж в натуральных единицах, что позволяет оптимизировать складские запасы и логистические ресурсы. На этапе проектирования ИС определяется состав прогнозов, которые будут использоваться менеджерами предприятия, их настойки, бизнес-процессы и регламенты применения. Таким образом, возможности ИС ERP по прогнозированию интегрируются в СУ.

Интеграция ИС и СУ на процедурном уровне обеспечивается на этапе проектирования путём разработки, оптимизации и согласования бизнес-процессов. В нашем списке задач ИС ERP, поддержка бизнес-процессов фигурирует под последним номером. Это место определяется логикой разработки проекта информационной системы, поскольку в бизнес-процессах на процедурном уровне фиксируются все ранее принятые решения по организации управления по показателям, учёту, документообороту, планированию и прогнозированию.
Бизнес-процессы разрабатываются в тесной связи с другими документами организационного дизайна компании. Например, права участников бизнес-процессов должны быть согласованы со структурой управления, а выполняемые функции – с должностными инструкциями. Схемы бизнес-процессы требуют дополнения регламентами, содержащими информацию, разъясняющую детали исполнения бизнес-процессов. Фактически, при разработке этой части проекта ИС ERP, формируется весь пакет организационных документов компании или проводится ревизия существующего оргдизайна.
Оптимизация бизнес-процессов – это отдельная серьёзная задача, требующая большого опыта и квалификации. Предложения по косметическому улучшению бизнес-процедур возникают уже на первом шаге при формализации и согласовании бизнес-процессов «как есть». Более глубокая оптимизация может быть предложена на основе анализа стратегии и тактики компании, который проводится в ходе первого этапа управленческого консалтинга – диагностики системы управления. Разумеется, глубина реинжиниринга бизнес-процессов определяется руководством компании.
До определённого уровня детализации описание бизнес-процессов не зависит от выбранной для внедрения платформы ИС. Однако, при проектировании информационной системы полезно детализировать бизнес-процессы до документов конкретной ИС, что позволяет в дальнейшем использовать такие описания в качестве инструкций операторов, а также для формирования сценариев обучения пользователей.
Несколько слов о процедуре выполнения этапа управленческого консалтинга проектирования ИС класса ERP. На рис. 1 представлена общая процедура совершенствования системы управления предприятием, а пунктиром выделены работы, относящиеся к услуге проектирования ИС.

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

Рис. 1. Общая процедура Управленческого консалтинга

Процедура этапа управленческого консалтинга проектирования ИС ERP начинается с диагностики системы управления предприятием , которая проводится в следующей последовательности:
1. Ознакомление с материалами компании
2. Совещание с руководителем компании, на котором уточняются
• направления деятельности компании (продукты, рынки сбыта)
• состояние системы управления
• список ведущих сотрудников, зоны ответственности
• существующие проблемы
• график интервью с ведущими сотрудниками компании
3. Интервью с ведущими сотрудниками
5. Анализ существующих документов системы управления
6. Подготовка предложений по развитию системы управления
7. Подготовка предложений по плану работы
После согласования плана работы с заказчиком, разрабатывается функциональный проект ИС, ссылка на пример в конце статьи.
В процессе настроек ИС и доработок типового функционала консультант взаимодействует с внедренцами по вопросам формирования постановок задач и технических заданий, а в процессе обучения пользователей и внедрения ИС ERP в опытную эксплуатацию консультирует пользователей по вопросам, находящимся в его компетенции. Таким образом, работа консультанта начинается на самом раннем этапе проектирования информационной системы и заканчивается только после внедрения управленческой ИС.

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

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

Как заказать наши услуги

УЗНАТЬ ПОДРОБНЕЕ

1. Наши услуги
2. Сколько стоит консалтинг?
3. Примеры работ
4. Отзывы клиентов
5. Подписка на рассылку

Источник: piter-consult.ru