Сколько стоит разработка с нуля собственной системы управления компанией?

Сколько стоит разработка с нуля собственной системы управления компанией?

Таким вопросом задаются многие компании на определенном этапе развития.

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

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

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

Заказчик

Охранное предприятие с широким спектром услуг, в штате — более тысячи сотрудников, работающих в 60 регионах страны.

Задача

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

Имеющиеся ИТ-системы

1C:Бухгалтерия 8

1С:ЗУП 8

Артефакты для оценки

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

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

Проще было бы ответить: «С вероятностью в 50%, мы сделаем это за 100 млн рублей в течение 5 лет». Безусловно, такой ответ вряд ли бы устроил заказчика.

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

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

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

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

Анализ бизнес-целей

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

  • Сократить нагрузку на сотрудников мониторингового центра, которые каждые три часа получают звонки с более чем 2000 постов охраны. А также ускорить время реакции на инциденты за счет высвобождения ресурса.
  • Оптимизировать процесс расчета заработной платы за счет своевременного получения информации об отработанных часах охранников и автоматической передачи этих данных в 1С:ЗУП
  • Повысить качество услуг за счет четкой и своевременной фиксации чрезвычайных ситуаций и клиентских замечаний в электронных журналах. А также информировать руководство через регулярную рассылку оперативных сводок.
  • Иметь актуальную и достоверную информацию по действующим сотрудникам (наличие необходимых документов, регламентированных законодательством) и их фактической выработке.
  • Повысить квалификацию охранников за счет доступа к базе знаний и профессиональным обучающим курсам.

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

Подготовка технического задания

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

Результат этапа — верхнеуровневое ТЗ на создание MVP системы, состоящее из следующих задач:

  • разработка web-портала — ключевого элемента информационной системы, в котором реализованы такие разделы как: структура компании (основные объекты, личный состав); база знаний с полезными статьями и лента новостей; перечень проводимых проверок; график табель, который интегрирован с 1С:ЗУП для оперативного обмена данными о фактически отработанном времени сотрудников; мониторинговый центр, где консолидируется вся информация об инцидентах и клиентских замечаниях; журнал вызовов группы быстрого реагирования; личный профиль сотрудника.
  • реализация «Виртуального дежурного» — робота, способного идентифицировать сотрудника охраны, подтягивать информацию об объекте по номеру телефона, с которого поступил звонок, обрабатывать входящие звонки от сотрудников, вызывать группу быстрого реагирования в случае чрезвычайной ситуации, а также сохранять записи звонков.
  • разработка функционала автоматического добавления фактически отработанных часов в график-табель на основании звонка от сотрудника.
  • реализация механизма по вызову группы быстрого реагирования при получении сигнала тревоги от сотрудника охраны в процессе отзвона на виртуального дежурного. Вся информация о вызовах и их статусах регистрируется в журнале вызовов ГБР для последующего анализа и отчетности.

Оценка проекта

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

Чтобы сформировать максимально объективную оценку, мы собираем архитектурный совет из нескольких опытных разработчиков. Их задача — сформировать единое техническое видение проекта и предложить архитектуру будущего решения на основании написанного бизнес-аналитиком верхнеуровневого ТЗ. Команда архитектурного совета раскладывает функциональные блоки на укрупненные задачи и дает оценку по времени реализации блока по всем направлениям: backend, frontend, mobile, бизнес- и системный анализ, дизайн, тестирование и управление будущим проектом.

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

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

Срок разработки системы, по нашей оценке, составит 10-14 месяцев. Стоимость — 60-80 млн рублей.

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

Много это или мало?

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

А как думаете вы?

77
реклама
разместить
2 комментария

Кажется, что можно это сделать на 1С в связке с Битриксом. Но масштабировать потом будет больно и дорого

1

Мы не делаем на Битрикс) И да, масштабироваться и выполнять желания заказчика по доработке будет труднее.