Бизнес план подрядной it организации

Для разработки своего IT стартапа (рекрутинговая веб-платформа) по крупицам создал детальную структуру бизнес-плана. Далее, проработав каждый пункт, получил ясную и понятную картину будущего Бизнеса. Структура охватывает все важные направления как для создателя, так и для инвестора. Адаптировано для рынков США и Европы.
Шерю для всех.

1.) Коротко о проекте (Что привносит проект на рынок?)
1.1.) Почему? (Мечта, видение, причина, вера, главная цель Бизнеса)
1.2.) Как? (миссия)
1.3.) Краткое описание сути Проекта
1.4.) Детальное описание Проекта
1.5.) Решаемые Проектом проблемы
1.6.) Долгосрочные цели проекта
1.7.) Бизнес-концепт: обзор проекта / описание ноу-хау

2). Функционал (Технологическое решение проекта)
2.1.) Краткое описание платформы
2.2.) Детальное описание платформы
2.3.) Дополнительные модули, услуги
2.4.) Тех. задание – веб платформа

3). Для кого (Рынок, пользователи, клиенты проекта)
3.1.) Портрет целевой аудитории
3.2.) Характеристики целевого рынка аналогичных продуктов / услуг

• Структура рынка (размер и сегментация) Динамика.
• Наиболее важные сегменты потребителей
• Ключевой вывод по структуре
• Прогноз по целевым сегментам рынка.
• Ключевой вывод по трендам целевых сегментов
• Проблемы и потребности рынка, взаимоотношения основных участников рынка
• Ключевой вывод по ключевым вызовам
• Ключевой вывод о ситуации на целевом рынке

3.3.) Уникальное торговое предложение

4. Обзор бизнес-модели
4.1.) Деятельность

• В чем заключается деятельности компании?

4.2.) Ценность для потребителей

• Какой набор продуктов/услуг предоставляется потребителям?
• Какую ценность проект несет для потребителей?
• Какие потребности и проблемы потребителей решает проект?

4.3.) Сегменты потребителей

• Все целевые сегменты потребителей
• Наиболее важные сегменты потребителей

4.4.) Ресурсы

• Какие ресурсы используются для создания ценности?

4.5.) Отношения с клиентами

• Какие типы коммуникаций планируется выстроить для каждого сегмента потребителей?
• Какой уровень сервиса?

4.6.) Дистрибуция

• Каналы продаж
• Стоимость каналов продаж
• Приоритизация каналов продаж

4.7.) Партнеры

• Партнеры
• Поставщики
• Ресурсы, получаемые от партнеров
• Основные активности партнеров

4.8.) Структура расходов

• Постоянные издержки, переменные издержки
• Какие ресурсы наиболее затратные?

4.9.) Потоки доходов

• За что готовы платить потребители?
• Какие способы оплаты возможны?
• Какие потоки доходов наиболее прибыльные?

4.10.) Основные бизнес процессы

5.) Конкуренция. Преимущества
5.1.) Список основных конкурентов
5.2.) Что обычно предлагают конкуренты на рынке?
5.3.) Что предлагает проект?
5.4.) Сводный анализ конкерентов
5.5.) Анализ лучшей практики (ряд примеров использования аналогичных бизнес-решений (возможно, из других отраслей)

6.) Модель монетизации для каждого продукта
6.1.) Принципы монетизации
6.2.) Ключевые цели и методы
6.3.) Количество потенциальных пользователей
6.4.) Маржинальность

7.) Стратегический потенциал проекта (Почему проект будет успешен в будущем)

8.) Ключевые факторы успеха
8.1.) Внешние факторы
8.2.) Внутренние факторы

9.) Команда проекта
9.1.) Ключевые лидеры
9.2.) Команда
9.3.) Советники

10.) Статус проекта
10.1.) Хронология (История развития)
10.2.) Текущий статус (Что уже сделано — статистика финансовых и других измеримых показателей деятельности)
10.3.) Достижения на данный момент

11.) Направления развития проекта. Цели. (Направления деятельности в рамках проекта, по которым запланирована или уже ведется работа)

12.) Дорожная карта (План реализации проекта. Основные вехи)
12.1.) Период
12.2.) Фокус

13.) Прогноз продаж, лежащий в основе финансовой модели (Сценарии)

14.) Инвестиционно-финансовые показатели проекта
14.1.) Прогноз чистых денежных потоков
14.2.) Необходимый объем инвестиций
14.3.) Период окупаемости
14.4.) IRR

15.) Долгосрочная инвестиционная стратегия (Стратегия развития / выхода)

16.) Инвестиционное предложение
16.1.) Условия участия

• Оценка проекта
• Необходимый объем инвестиций
• Долевое участие инвестора
• Структура бюджета
• Финансирование

16.2.) Показатели

• Годовой оборот компании через 3 года
• Оценка компании через 3 года

16.3.) Раунды финансирования (транши)
16.4.) Сроки (подачи заявок, закрытия сделки)

17.) Фин. модель

18.) Маркетинг. Медиаплан

19.) Модель управления

20.) Система KPI

21.) Стратегия выхода

22.) Юридические аспекты

23.) Разное

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

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

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

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

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

Нанять организацию предоставляющую услуги ИТ консалтинга передав ей полный ИТ суппорт бизнеса тоже не правильно.

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

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

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

По моему мнению – правильно разделить процесс разработки. Где анализ и постановка задач формируется внутри организации, а непосредственно разработка – передается подрядчику.

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

Менеджер (владелец системы)
Что делает
Определяет стратегию развития, в каком направлении развивается система, что будет нужно предприятию от этой системы через год, возможно два. Утверждает бюджеты. Отвечает за работу с подрядчиком в целом. Утверждает задачи подрядчику. Устанавливает приоритет по задачам.

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

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

Аналитик
Что делает
Описывает текущие процессы в компании в виде внутренних документов.

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

Превращает пространственные пожелания внутренних заказчиков в конкретный документ – бизнес требования. Отвечает за соответствие бизнес требований изначальным пожеланиям заказчиков.

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

Что не делает
Не принимает управленческих решений, только предлагает их. Не устанавливает приоритеты по задачам для подрядчика. В общих чертах разбирается в ИТ и поэтому не передает абсолютно нереализуемые идеи архитектору. В переговорах с подрядчиком не имеет права на собственное мнения – озвучивает только то, что согласовано с руководством.

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

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

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

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

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

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

Характеристики
Должен обладать абсолютными знаниями по системе. А так же глубокими знаниями как технологий так и процессов ИТ в целом. Уметь вести переговоры, грамотно аргументировать свою точку зрения – от него зависит конечная цена работ и качество получаемого продукта.

Администратор
Что делает
Работает с пользователями. Заводить и удалять из системы, обнулять пароли. Консультировать по вопросам типа, что нужно нажать что бы открылась эта форма или почему неактивна та кнопка.

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

Устанавливать полученные от подрядчика пакеты на тестовую среду. Принимать участие в приемочном тестировании пакетов на тестовой среде. Устанавливать пакеты на основную среду после приемки работ.

Составляет паспорт, договор о предоставлении услуг пользователям и другие внутренние документы по системе.
Все действия которые может производить администратор должны быть описаны в «Руководстве администратора» которое составляет поставщик системы и поддерживает его актуальность после обновлений и доработок системы.

Что не делает
Не производит собственных доработок или изменений системы.

Характеристики
По сути, его работа это сплошная рутина. От него не требуется особых знаний. Должен выполнять пару десятков операций. Большинство из которых должны быть описаны в «Руководстве администратора». Но требуется внимательность стрессоустойчивость и ответственность.

Подрядчик (понятно, что со стороны подрядчика так же работает целая команда, но с точки зрения заказчика – они единое целое)

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

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

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

Не имеет доступа к основной среде. К тестовой среде – возможно, но без права внесения изменений. Вся разработка должна вестись на девелоперской среде.

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

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

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

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