66
10. Требуется ли возможность внесения изменений в существующий
показатель? Или смена показателей должна происходить через функционал
удаление/создание нового показателя?
11. Требуются ли напоминания пользователям о событиях в системе
(например, приближающейся дате отчета)? Какие? Кому?
12. Как планируется осуществлять ввод и корректировку плановых
показателей? Какие уведомления при этом должны быть реализованы?
13. Какие уровни доступа требуется реализовать в системе?
14. Какие еще моменты вы хотели обсудить/озвучить в свете
обсуждаемого решения?
Далее ответы всех участников интервью были проанализированы,
сформулированы в виде документа «ТЕХНИЧЕСКОЕ ЗАДАНИЕ ДЛЯ
СИСТЕМЫ ВИЗУАЛИЗАЦИИ ЗНАЧЕНИЙ КЛЮЧЕВЫХ ПОКАЗАТЕЛЕЙ
ДЕЯТЕЛЬНОСТИ ГК «Х»» и согласованы с заказчиком.
2.5. Риски разработки
Был составлен и проанализирован список возможных рисков
разработки. В текущем контексте под риском понимается событие,
наступление которого наносит ущерб какой-либо деятельности.
Имеется в виду будущее событие.
Событие должно быть случайным (т. е. заранее неизвестно,
произойдет оно или нет).
Таким образом, риск – это событие, которое препятствует
выполнению проекта в соответствии с условиями договора, то есть в
установленный срок, в рамках определенного бюджета, с оговоренными
результатами.
Был составлен реестр рисков (таблица 14 в Приложении). Риски были
оценены по двум параметрам: степень влияния и вероятность реализации:
Влияние риска на результат проекта:
Низкое – 1 балл
Среднее – 3 балла
67
Высокое – 5 баллов
Вероятность реализации риска:
Низкая – 1 балл
Средняя – 3 балла
Высокая – 5 баллов
Риски были сгруппированы. Результаты представлены на рисунке 10.
Затем каждому риску была присвоена оценка в баллах (в зависимости
от этих двух показателей – среднее от двух оценок). Результат – проставлен в
графе «Ранг риска». В таблице риски отсортированы по этому признаку от
максимальных значений к минимальным.
Принято решение не принимать к реализации сценарии для рисков,
чья оценка ниже 3 в графе «Ранг риска».
воздействие
3
Заказчик откажется от
реализации проекта
после составления ТЗ.
Функционал не будет
реализован
разработчиком
Стоимость разработки
превысит сумму
выставленного
заказчику счета
Сложная интеграция с
системами заказчика,
не учтенная при
проектировании
Срок реализации
сильно растянут во
времени
2
Реализованный
функционал не будет
устраивать заказчика.
ПО заказчика не будет
совместимо в
реализованной
системой
ТЗ не удастся быстро
согласовать со всеми
заинтересованными
сторонами.
В процессе
эксплуатации будут
обнаружены
недочеты.
Неприятие
сотрудниками,
задействованными во
внедрении. Скрытая
или явная
деятельность по
саботированию
проекта
1
Исполнитель
не справится
с задачей
Инфраструктура
заказчика не позволит
развернуть решение
Неприятие
сотрудниками
заказчика работы в
новой системе
Затягивание
заказчиком сроков
завершения работ по
проекту
1
2
3
вероятность
Обозначения:
1 – низкое/низкая, 2 – среднее/средняя, 3 – высокое/высокая
Рисунок 10 Анализ рисков проекта. Ранг риска и матрица
вероятностей и последствий
Риски были сгруппированы по трем основным категориям, по каждой
категории были сформулированы профилактические мероприятия,
68
минимизирующие соответствующую группу рисков. Результаты
представлены в таблице 6.
Таблица 6
Группы рисков при разработке
Наиме-
нование
риска
Описа-
ние
Возможные
причины
Вероятный
результат
Некоторые
профилактичес-
кие меры
Выход из
бюджета
Превыш
ение
бюджета
проекта
Заложенный в
проект бюджет
не реализуем.
Бюджет вырос
по мере
развития
проекта,
прежде всего,
за счет
постоянных
изменений,
вносимых в
проект
Затягивание
проекта.
Угроза
финансовому
благополучию
компании.
Отслеживать
стоимость
проекта.
Минимизировать
этапы внедрения.
Писать детальное
ТЗ на конкретный
этап.
Четко оговаривать
условия
реализации.
Согласовать план-
график и бюджет
проекта.
Затягиван
ие
проекта и
недостатк
и
реализац
ии
Отторже
ние
проекта
заказчик
ом
Недостатки
политики
внедрения,
выбранной
заказчиком.
Недостатки
интерфейса
пользователя.
Проваленный
проект
Формулировка
политик
внедрения.
Участие в
разработке
политики
внедрения
заказчика.
Вовлечение в
проект будущих
пользователей.
Изменяем
ость
требовани
й
Постоян
ные
изменен
ия,
инициир
уемые
заказчик
ом
Отсутствие
дисциплины
реализации
проекта
Проваленный
проект
Внедрять
управление
изменениями.
2.6. План-график разработки
Был составлен план-график разработки. Для составления была
использована программа MS Project. В программе была сформирована
диаграмма Ганта.
Таблица 7
План-график разработки
69
№
СДР
Название задачи
Длитель-
ность
Начало
Окон-
чание
Предшест-
венники
Трудо-
затраты
1
1
Автоматизация
системы KPI
154 дней
20.01.15
21.08.15
248 ч
2
1.1
Планирование и
подготовка
36 дней
20.01.15
10.03.15
72 ч
3
1.1.1
Согласование
основных моментов
5 дней
20.01.15
26.01.15
8 ч
4
1.1.2
Согласование
рамочного договора
10 дней
27.01.15
09.02.15
3
8 ч
5
1.1.3
Рамочный договор
подписан
0 дней
09.02.15
09.02.15
4
0 ч
6
1.1.4
Подготовка ТЗ
17 дней
10.02.15
04.03.15
48 ч
7
1.1.4.1
Интервьирование
фокус-группы
5 дней
10.02.15
16.02.15
5
8 ч
8
1.1.4.2
Подготовка и
согласование ТЗ
12 дней
17.02.15
04.03.15
7
40 ч
9
1.1.4.3
ТЗ согласовано
0 дней
04.03.15
04.03.15
8
0 ч
10
1.1.5
Подготовка
документации по
проекту
4 дней
05.03.15
10.03.15
8
8 ч
11
1.1.6
Договор и ТЗ на
разработку
подписаны
0 дней
10.03.15
10.03.15
10
0 ч
12
1.2
Разработка и
внеднерие
113 дней
11.03.15
14.08.15
168 ч
13
1.2.1
Настройка
архитектуры
4 дней
11.03.15
16.03.15
11
2 ч
14
1.2.2
Разработка
элементов списков
8 дней
17.03.15
26.03.15
13
24 ч
15
1.2.3
Настройка
пользовательских
интерфейсов
4 дней
27.03.15
01.04.15
14
6 ч
16
1.2.4
Настройка
отчетов и правил
работы
10 дней
02.04.15
15.04.15
15
24 ч
17
1.2.5
Разработка
функционала
завершена
0 дней
15.04.15
15.04.15
16
0 ч
18
1.2.6
Приемочные
испытания
18 дней
16.04.15
11.05.15
32 ч
19
1.2.6.1
Разработка
сценариев
тестирования
4 дней
16.04.15
21.04.15
17
8 ч
20
1.2.6.2
Тестирование
по сценариям
5 дней
22.04.15
28.04.15
19
8 ч
21
1.2.6.3
Исправление
недочетов
4 дней
29.04.15
04.05.15
20
8 ч
22
1.2.6.4
Повторное
тестирование
5 дней
05.05.15
11.05.15
21
8 ч
23
1.2.6.5
Приемочные
испытания успешно
завершены
0 дней
11.05.15
11.05.15
22
0 ч
24
1.2.7
Подготовка к
опытной
эксплуатации
9 дней
12.05.15
22.05.15
24 ч
25
1.2.7.1
Разработка
документации
3 дней
12.05.15
14.05.15
23
8 ч
26
1.2.7.2
Обучение
ключевых
пользоватлей
3 дней
15.05.15
19.05.15
25
8 ч
27
1.2.7.3
Ввод начальных
данных
3 дней
20.05.15
22.05.15
26
8 ч
70
№
СДР
Название задачи
Длитель-
ность
Начало
Окон-
чание
Предшест-
венники
Трудо-
затраты
28
1.2.7.4
Система готова
к работе
0 дней
22.05.15
22.05.15
27
0 ч
29
1.2.8
Опытно-
промышленная
эксплуатация
60 дней
25.05.15
14.08.15
56 ч
30
1.2.8.1
Осуществление
поддержки
60 дней
25.05.15
14.08.15
28
40 ч
31
1.2.8.2
Устранение
замечаний
60 дней
25.05.15
14.08.15
28
16 ч
32
1.2.8.3
ОПЭ успешно
завершена
0 дней
14.08.15
14.08.15
31
0 ч
33
1.3
Завершающий
этап
5 дней
17.08.15
21.08.15
8 ч
34
1.3.1
Подготовка акта
5 дней
17.08.15
21.08.15
31
8 ч
35
1.3.2
Разработка
системы успешно
завершена
0 дней
21.08.15
21.08.15
34
0 ч
71
Рисунок 11 Диаграмма Ганта разработки
72
Был составлен и согласован бюджет проекта. Результаты
представлены в таблице 8.
Таблица 8
Бюджет проекта
№
п/п
Наименование,
кол-во часов
Состав этапа
Стоимость
этапа,
рублей
1
Подготовительный
этап (72 ч) – 36 дней
Подготовка документации по
проекту
Проведение установочной встречи
с участниками рабочей группы
Проведение интервью с
участниками рабочей группы
Проведение предварительного
показа системы
Составление и согласование ТЗ
Планирование работ
150 000,00
2
Разработка и
внедрение (168 ч) –
113 дней
Разработка функционала
Приемочные испытания
Подготовка к опытной
эксплуатации
Опытно-промышленная
эксплуатация
320 000,00
3
Завершающий
этап (8 ч) – 5 дней
0,00
ИТОГО:
470 000,
00
2.7. Модель монетизации
Написанное для клиента ТЗ является универсальным и не привязано к
специфике компании, значит, для внедрения системы произвольной
компании-клиенту нет необходимости в написании уникального ТЗ. При
этом затраты на написание ТЗ в модели монетизации можно не учитывать,
так как работа по его формированию уже была оплачена клиентом.
Универсальность искомого решения означает отсутствие в плане
работ этапов «Приемочные испытания», «Подготовка к опытной
эксплуатации» и «Опытно-промышленная эксплуатация», что также сократит
издержки.
Предлагается следующий вариант монетизации:
Дорабатываются шаблонные решения:
73
документация по системе (с тем, чтобы любая компания могла
воспользоваться универсальной документацией, и не пришлось ее
переписывать для конкретного клиента),
обучающие материалы (с тем, чтобы любая компания могла обучит
своих сотрудников работе с системой),
шаблон с готовыми настройками необходимых компонентов –
мастер сетапа нового клиента, включающий в себя некий шаблон настроек
системы.
Теперь можно с минимальными затратами подключать новых клиентов
к системе.
Мастер сетапа будет включать 2 этапа:
Настройка архитектуры
Настройка системы
Основные элементы (списки и базовые настройки) уже будут
зафиксированы, фактически, будет меняться только название компании-
клиента.
В предложенной модели затраты на внедрение будут включать в себя:
Написание мастера сетапа, подготовка шаблонов документов и
обучающих материалов – одноразово – порядка 90 часов. Предварительная
оценка инвестиций – 180 000 руб.
При всех выполненных работах внедрение системы для компании-
клиента будет занимать, ориентировочно, 1 час.
2.8. Инвестиционная привлекательность проекта
Можно проанализировать зависимость суммы продаж от стоимости
сетапа. Графическое распределение суммы продаж при различной стоимости
сетапа представлено на рисунке 12:
74
Рисунок 12. Сумма продаж при различной стоимости сетапа
Также определим точку безубыточности в зависимости от стоимости
сетапа для одной компании-клиента и построить график определяющий
точку безубыточности в зависимости от стоимости сетапа для одной
компании-клиента:
Рисунок 13. Точка безубыточности
Результаты приведены в таблице 9.
75
Таблица 9
Зависимость количества сетапов, которые необходимо провести
для достижения точки безубыточности от стоимости одного
сетапа.
Стоимость
сетапа, тыс. руб.
10
20
30
40
50
60
70
80
90
100
Точка
безубыточности
(кол-во сетапов)
23
10
7
5
4
4
3
3
3
2
ВЫВОДЫ ПО ГЛАВЕ 2
Приведено исследование российского рынка решений для
автоматизации управления KPI. Выявлены основные предлагаемые продукты
и предложены критерии для анализа подобных систем. Из результатов
исследования сделан вывод о возможности предложения на рынке
универсального и недорого (по срокам и стоимости сетапа) решения.
Было сформулировано техническое задание на разработку системы по
результатам обследования компании-заказчика ГК «Х». Техническое
задание, подготовленное для клиента, является универсальным и не
привязано к специфике компании. На основании этого описания и
предлагается формирование универсальной системы.
При этом затраты на разработку носят преимущественно разовый
характер и включают в себя доработку шаблонных решений:
документация по системе (с тем, чтобы любая компания могла
воспользоваться универсальной документацией, и не пришлось ее
переписывать для конкретного клиента),
обучающие материалы (с тем, чтобы любая компания могла обучит
своих сотрудников работе с системой),
шаблон с готовыми настройками необходимых компонентов –
мастер сетапа нового клиента, включающий в себя некий шаблон настроек
системы.
С точки зрения возврата инвестиций, проект также выглядит
достаточно привлекательным. Учитывая низкую стоимость нового клиента
для компании и невысокий ценовой порог, что сможет привлечь достаточно