2 Описание системы управления инновацией

2.1 Функциональная модель инновации в стандарте idef0

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

Имя модели – Внедрение Overdraft Banking Service в ООО «Сetelem Bank». Создаем контекстную диаграмму (Рисунок 2.1.1) для нашего проекта.

Рисунок 2.1.1 – Контекстная диаграмма функциональной модели проекта внедрение услуги Overdraft Banking Service.

Вход: требования заказчика.

Управление: стандарт PMBOK 2004, методические указания.

Механизмы: руководитель сервисного отдела, менеджер проекта, Исполнитель (инженер), руководитель проекта.

Выход: Услуга Overdraft Banking Service.

На рисунке 2.1.2 представлена декомпозиция контекстной диаграммы.

Рисунок 2.1.2 – Декомпозиция контекстной диаграммы

На рисунке 2.1.3 представлена декомпозиция блока «Выполнить инициацию проекта».

Рисунок 2.1.3 – Декомпозиция блока «Выполнить инициацию проекта»

На рисунке 2.1.4 представлена декомпозиция блока «Выполнить планирование».

Рисунок 2.1.4 – Декомпозиция блока «Выполнить планирование»

На рисунке 2.1.5 представлена декомпозиция блока «Осуществить исполнение проекта».

Рисунок 2.1.5 – Декомпозиция блока «Осуществить исполнение проекта»

На рисунке 2.1.6 представлена декомпозиция блока «Выполнить мониторинг и контроль».

Рисунок 2.1.6 – Декомпозиция блока «Выполнить мониторинг и контроль»

На рисунке 2.1.7 представлена декомпозиция блока «Выполнить закрытие проекта».

Рисунок 2.1.8 – Декомпозиция блока «Выполнить закрытие проекта»

2.2 Исследование бизнес-процессов инновации

На рисунке 2.2.1 представлен бизнес-процесс «Внедрение услуги Overdraft Banking Service на ООО «Cetelem Bank» в формате IDEF3. Языком IDEF3 является язык диаграмм, помогающий разработчику наглядно представить моделируемые процессы.

Рисунок 2.2.1 – Бизнес-процесс «Внедрение услуги Overdraft Banking Service на ООО «Cetelem Bank»

Таким образом, нами были смоделированы бизнес-процессы внедрения и разработки инновации.

2.3. Информационная модель

Информационная модель проекта представлена на рисунке 2.8. Построение информационных моделей (стандарт IDEF1X) осуществляется в программе ERwin.

Рис. 2.3.1 – Информационная модель

2.4 Модели рисков, определенные с использованием технологии fmea

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

Этапы исследования модели:

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

II) Выявляются потенциальные причины дефектов.

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

Этот фрагмент раздела завершается диаграммой причин-следствий в

Причины, приводящие к проблеме распределяют по принципу «6М»:

• Границы проекта, организация проекта - причины, связанные с человеческим фактором;

• Надежность − причины, связанные с ПО и оборудованием;

• Архитектура решения − причины, связанные с моделированием бизнес-процессов;

• Клиент, партнер − причины, связанные с сотрудничеством, а также возможные проблемы со стороны заказчика.

• Окружение проекта − причины, связанные с сопровождением проекта.

Рис. 2.4.1 - Диаграмма Исикавы

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

III) Определяют потенциальные последствия дефектов для потребителя.

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

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

IV) Возможности контроля появления дефектов.

Определяется, может ли дефект быть выявленным до наступления последствий в результате предусмотренных в объекте мер по контролю, диагностике и др. Информация о возможности контроля заносится в пятую колонку сводной таблицы (Таблица 2.4.1).

V) Определяется параметр тяжести последствий для потребителя (экспертно в 10-ти балльной шкале; наивысший балл проставляется для случаев, когда последствия дефекта влекут юридическую ответственность). Значение параметра заносится в шестую колонку сводной таблицы (колонка «B» 9).

VI) Определяется параметр частоты возникновения дефекта (экспертно в 10-ти балльной шкале; наивысший балл проставляется, когда оценка частоты возникновения составляет 25% и выше). Значение параметра заносится в седьмую колонку сводной таблицы (колонка «A» Таблица 2.4.1).

VII) Определяется параметр вероятности не обнаружения дефекта (экспертно в 10-ти балльной шкале; наивысший балл проставляется для «скрытых» дефектов, которые не могут быть выявлены до наступления последствий). Значение параметра заносится в восьмую колонку сводной таблицы (колонка «E» Таблица 2.4.1).

VIII) Определяется параметр риска потребителя (показывает, в каких отношениях друг к другу в настоящее время находятся причины возникновения дефектов; дефекты с наибольшим коэффициентом приоритета риска подлежат устранению в первую очередь). Параметр риска определяется перемножением коэффициентов «B», «A», «E»:

IX) Выявляются узкие места. Разрабатываются корректирующие мероприятия.

Таблица 2.4.1 — Сводная таблица FMEA-анализа

Таблица FMEA анализа объекта (функции)
Компонент	Потенциальный дефект	Потенциальные причины	Потенциальные последствия	Контроль	В	А	Е	RPZ
1	2	3	4	5	6	7	8	9
Границы проекта	Неопределенность целей, критериев успеха	Отсутствие плана проекта	Недостижение эффективности	Создание проекта	2	4	5	40
Границы проекта	Перенос неоптимизированных процессов	Не учтены неоптимизированные процессы	Риск снижения эффективности	Учет неоптимизированных процессов	4	3	2	24
Надежность	Недостаточная производительность	Отсутствие критериев эффективности	Снижение производительности	Доработки системы	2	5	6	60
1	2	3	4	5	6	7	8	9
Надежность	Ошибки	Невнимательность разработчика	Сбой в работе, простои	Контроль	7	4	3	84
Надежность	Ограниченная доступность	Сбой в системе	Сбой в работе, простои	Диагностика	2	5	4	40
Оборудование	Неполадки сервера	Поломка	Невозможность работы	Диагностика, резервирования	5	2	7	70
Оборудование	Неполадки оборудования	Поломка	Невозможность работы	Диагностика	5	2	7	70

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

План внедрения корректирующих мероприятий содержит:

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

2) Ответственного за проведение каждого мероприятия;

3) Исполнителя мероприятия;

4) В каком структурном подразделении должно быть проведено мероприятие;

5) Источник финансирования мероприятия.

Таблица 2.2 — План корректирующих мероприятий по устранению причин дефектов

№ п/п	Наименование мероприятия	Достигаемый эффект	Сроки исполнения мероприятия	Оценка сроков, когда проявится запланированный эффект	Ответственный на мероприятие	Исполнитель мероприятия	Структурное подразделение	Источник финансирования
1.	Планирование качества будущих процессов сопровождения на ранних этапах внедрения	Устранение риска ненадежности	01.04-10.04	30.04.14	Ответственный исполнитель	Инженер	Сервисный отдел	Нераспределенная прибыль
2.	Поиск возможности оптимизирующих, корректирующих действий	Устранение риска несоответствия бизнесу	10.04.14-10.08.14	30.04.14	Ответственный исполнитель	Инженер	Сервисный отдел	Нераспределенная прибыль
3	Планирование, согласование целей критериев успеха для проекта с топ-менеджментом	Устранение риска неопределенности целей	10.04.14-15.04.14	15.04.14	Ответственный исполнитель	Инженер	Сервисный отдел	Нераспределенная прибыль
4	Планирование будущих процессов сопровождения, выделение адекватного бюджета на эти цели	Устранение риска адекватности структуры сопровождения	10.04.14	30.05.14	Ответственный исполнитель	Инженер	Сервисный отдел	Нераспределенная прибыль
5.	Создание управляющего комитета, выделение архитектуры проекта	Устранение различных центров принятия решений	10.05.14-12.05.14	12.05.14	Ответственный исполнитель	Инженер	Сервисный отдел	Нераспределенная прибыль

Продолжение таблицы 2.2

6.	Подбор программы обучения	Повышение компетентности пользователей и команды	10.04.14-15.04.14	30.05.14	Ответственный исполнитель	Инженер	Сервисный отдел	Нераспределенная прибыль
7.	Организация системы качества разработок	Снижение рисков архитектуры	10.04.14-15.04.14	15.04.14	Ответственный исполнитель	Инженер	Сервисный отдел	Нераспределенная прибыль
8.	Тщательный выбор партнера	Риск некомпетентности партнера	10.04.14-15.04.14	15.04.14	Ответственный исполнитель	Инженер	Сервисный отдел	Нераспределенная прибыль
9.	Предпроектный анализ, диагностика и реализация модификаций	Эффективность организации проекта, управление изменениями	10.04.14-15.04.14	30.05.14	Ответственный исполнитель	Инженер	Сервисный отдел	Нераспределенная прибыль

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