Разрабатывать нельзя внедрять
Вы знаете, что в однобортном уже никто не воюет? Мы не готовы к войне!
Из к/ф «Тот самый Мюнхгаузен»
Начиная эту статью, я вспомнил, как несколько лет назад пытался объяснить своему другу разницу между тиражируемым ПО и разработкой индивидуального решения. Я на ходу менял используемые термины и ракурсы, и, наконец, пришел к выводу, что объяснить-то я могу, только вот еще и самому понять хотелось бы.
Этот разговор стал для меня отправной точкой, которая заставила переосмыслить ситуацию разработки программного обеспечения с совершенно разных сторон.
Обычно на вопрос о различиях между тиражируемым и заказным ПО следует ответ, в котором содержится хотя бы один из факторов, разделяющих эти два понятия:
• приобретаемые права;
• степень готовности;
• уникальность;
• функциональная ограниченность.
Вот и давайте все это рассмотрим по порядку.
Права
С точки зрения приобретаемых прав в одном случае заказчик получает лишь лицензию на использование, в другом – права полностью. Кажется, что это очевидно. Но и в этом случае возможны варианты, когда в целях экономии на услугах разработки заказчик получит только права на использование, давая возможность подрядчику перепродать полученное решение. Вроде бы и разработка, а вроде и шаг к коробке.
Степень готовности
Как правило, трудозатраты на внедрение отражают степень индивидуальности решения. Безусловно, сравнения должны производиться между системами примерно одинаковой функциональности, но и тут не обходится без тонких моментов, когда внедрение коробочного продукта может стать сопоставимым с разработкой индивидуального решения. Так что порой грань между достаточно сложной настройкой системы управления предприятием и написанием индивидуального модуля к аналогичной системе стирается.
Заказывая индивидуальную разработку программного комплекса, компания рассчитывает как на удовлетворение своих индивидуальных потребностей, так и на уникальность самой системы. Но так ли это? Обращаясь к разработчикам, заказчик всегда смотрит на наличие опыта разработок именно в этой сфере. Но наличие опыта обозначает не только присутствие знаний и компетенции, но и определенных наработок, которые обязательно будут использоваться, чтобы снизить сроки исполнения заказа и сократить бюджет разработки. А эти наработки и становятся элементами тиражируемости, которые компания получает в рамках индивидуального подхода.
Функциональная ограниченность
Любое тиражируемое ПО изначально имеет четкие ограничения по функциональности. При разработке на заказ одним из основных моментов как раз и является создание продукта, более глубоко учитывающего потребности компании. Но снятие ограничений может стать новым препятствием, которое проявится при изменении бизнес-процессов компании. А у тиражируемого ПО может найтись модульная структура, способная обеспечить поддержку изменяющихся требований. Поневоле приходит на ум аналогия с полной личной свободой, на которую накладываются ограничения в виде ненарушения чужих свобод.
Вот и получается, что, несмотря на различия между двумя решениями, размытость границ позволяет в одних и тех же случаях использовать различный подход к выбору. Области, где выбор очевиден, уже давно определены и ни у кого не вызывают сомнения (крупные системы ERP, MES, CRM), однако рядом есть и те области, в которых методология выбора решения вовсе не так однозначна.
Выбор
Итак, наступает момент, когда необходимо осознанно сделать выбор в пользу того или иного решения. Этой теме посвящен не один десяток статей, в них показываются преимущества и недостатки вариантов, предлагается помощь в выборе, приводится анализ имеющихся на рынке решений.
Но в процессе выбора участвует не только «внешняя сторона», а еще и внутренняя, связанная с самоидентификацией компании. Ведь именно она определяет тот путь, который компания должна пройти.
Задумайтесь над следующими вопросами:
• Какие компании являются конкурентами моей компании?
• Чем моя компания похожа на конкурентов?
• Чем моя компания отличается от конкурентов?
Достаточно ли ответа на эти вопросы, чтобы решить, что делать дальше? Нет. Это лишь первый шаг, который заставляет задуматься о том, что сейчас есть. Как правило, уже тут проявляется определенное раздвоение в виденье информационной системы, потому что есть то, что реально существует, и то, что потенциально возможно, что максимально подошло бы текущему состоянию компании. Но мы ведем речь о внедрении системы, значит, думаем не только о настоящем, но и о будущем. А значит, надо ответить и на следующие вопросы:
• Какие компании я хочу видеть в качестве конкурентов?
• В чем моя компания может оставаться похожей на конкурентов?
• Чем моя компания должна отличаться от конкурентов?
Мысли приняли другой оборот, они стали быстрее, энергичнее. И инструменты, которые потребуются компании, чтобы поддержать желаемые темпы развития, могут оказаться совсем иными. Вы более четко видите два изначальных состояния системы и два пути развития, ведущие из каждого состояния в желаемое будущее. Именно эти два пути являются фундаментальной основой выбора решения, поскольку они оба должны вас привести в одну точку — успешное будущее компании.
Что же особенного в этих трех состояниях? Честно говоря, ничего. Ничего, кроме вашего осознания. Осознания состояния и ценностей, которые есть у вашего бизнеса. Ценности (время, цена, гарантированность результата и др.) различны, но непосредственно связаны с факторами, которые можно разбить на следующие группы (см.табл.1).
Таблица 1
|
Признаки |
Факторы |
|
Явные, формализуемые и прогнозируемые |
Стоимость (самый очевидный фактор в мире) |
|
Длительность разработки и внедрения | |
|
Наличие аналогичных разработок, как тиражируемых, так и индивидуальных | |
|
Наличие собственных квалифицированных ресурсов | |
|
Неявные |
Степень интеграции решения с ключевыми бизнес-процессами |
|
Стратегия развития компании и ее готовность к изменению бизнес-процессов | |
|
Готовность компании к сокращению своих требований и фиксированию особенностей системы | |
|
Индивидуальные |
Степень риска и возможные последствия, связанные с неадекватной реализацией необходимых функций |
|
Степень уникальности требуемого решения |
Разрабатывать или внедрять?
Конечно, никто не может однозначно сказать, что один из путей является правильным. На выбор пути влияет совокупность объективных факторов, субъективных условий и стратегии компании.
Можно сформировать матрицу, где в строках прописать вышеперечисленные факторы, а в столбцах расположить весовые коэффициенты. Суммируя их, удастся определить, какое же решение будет для компании более подходящим, но более удачным будет не искать, что выгоднее, а определить ситуации с максимальными рисками или максимальными возможностями, после чего выбирать решение, исходя из этих показателей.
Разрабатывать, нельзя внедрять
Что же может стать решающим аргументом, подвигающим компанию на индивидуальную разработку программной системы (см.табл.2)?
Таблица 2.
|
Аргументы |
Условия |
|
Уникальность задачи |
Исследовательские центры, автопроизводители и многие другие понимают, что от качества реализации их программного комплекса напрямую зависит весь их бизнес, процесс производства и положение на рынке. Если вы также остро чувствуете свою уникальность и зависимость от качества разработки, стоит начать искать программиста в штат или надежного подрядчика. |
|
Недолговечность проблемы |
В современном мире все меняется так быстро, что иногда временные решения, которые, по сути дела, являются заплатками, действительно экономят и деньги, и время компании, позволяя сфокусироваться на более важных задачах |
|
Финансовые ограничения при наличии внутренних ресурсов для проведения разработки |
Если у вас есть не полностью занятый программист, творческое задание ему может стать полноценным проектом, который поможет оптимизировать работу компании |
|
Вклад решения в добавленную стоимость |
Если услуга, которая требует от вас разработки ПО, может приносить компании больше денег именно за счет качества разработки и степени интеграции в ИС вашей компании, лучше потратить время на проработку такой системы |
Безусловно, могут появиться и другие факторы, но основные я постарался перечислить.
Разрабатывать нельзя, внедрять
Перечислить все моменты, когда стоит внедрять тиражируемое решение, практически нереально. Отмечу лишь те случаи, когда стоит еще раз подумать, потянете ли вы разработку или все же следует отказаться от такого опыта, несмотря на стойкое желание получить индивидуальное ИТ-решение (см.табл.3).
Таблица 3
|
Имеющиеся ограничения |
Пояснения |
|
Отсутствие человека, готового нести ответственность за постановку технического задания |
Именно «готового нести ответственность». Создание рабочих групп, планерки, летучки, тестирование… Все это теряет смысл, если ИТ-директор остается единственным ответственным. Очень часто звучат слова «бизнес-заказчик», «спонсор проекта», но они отражают только одну сторону медали – кому этот проект нужен. Второй стороной является готовность заказчика тратить свое время на участие в этом проекте. Если готовности нет, лучше забыть о разработке и искать максимально близкое тиражируемое решение, а в идеале вообще попробовать подобрать коробочную версию. Шансы того, что заказчик оценит скорость установки такого решения, очень велики |
|
Отсутствие в штате специалиста, имеющего достаточную квалификацию для приемки работ и организации тестовой эксплуатации |
Индивидуальное решение отличается ограниченным сроком поддержки в случае, если вы заказываете его у подрядчика. Поэтому приемка результата становится критически важным моментом, который может породить риск полной потери решения в случае некачественного исполнения |
|
Кадровые проблемы |
Наличие собственных специалистов является большим плюсом при разработке собственной системы, но надо очень внимательно отнестись к сопутствующим рискам. А что, если весь отдел разработчиков сократят? Или хотя бы половину отдела? Допустим, документирование разработок ведется не совсем так, как хотелось бы, да и ключевые разработчики жалуются на низкий уровень заработной платы… Тогда время заняться кадровым вопросом, но никак не запуском нового проекта, от функционирования которого может сильно зависеть бизнес компании |
|
Скорость |
Если перед вашей компанией поставлены жесткие временные рамки, сто раз подумайте, прежде чем браться за разработку. Крайне небольшое число проектов сдаются в срок, причем зачастую не по вина подрядчика. Сроки в договоре привязаны к датам платежа, произошла задержка-другая — и вот еще пара недель потеряна |
|
Финансовый вопрос |
Если существует нестабильность в финансовом обеспечении, лучше проводить все выплаты в максимально короткие сроки, а это значит, что о разработке лучше не думать. Как говорится, «хотите потерять друга – дайте ему в долг». Нет более простого способа завалить проект, чем начать задерживать выплаты подрядчикам |
Все эти особенности могут присутствовать в любой компании, независимо от ее размера, сферы деятельности и успешности. Но если сфера деятельности и другие параметры очевидным образом влияют на выбор решения (наличие тиражируемых специализированных решений для данной отрасли, стоимость существующих решений), то влияет ли на этот выбор размер компании?
Размер имеет значение
Дело не столько в финансовых возможностях компаний разного уровня, сколько в их инструментах и требованиях к этим инструментам.
Крупные компании могут позволить себе не только открыть свой центр разработки, но и обеспечить полный жизненный цикл разрабатываемого продукта. Такие подразделения регулярно выделяются внутри крупных компаний, регулярно выводятся в отдельный бизнес и регулярно закрываются. Все это связано с управляемостью, глобальной рыночной ситуацией и стратегией компании. И основная заслуга людей, начинающих разработку собственного ПО в таких компаниях, заключается в правильной организации процесса разработки и поддержки, чтобы при изменениях в компании разрабатываемое ПО продолжало бы максимально эффективно функционировать и поддерживаться.
Средний бизнес, как правило, отличается специализацией, поскольку не может себе позволить диверсификации, если только она напрямую не влияет на прибыльность. Поэтому, если у компании есть штат программистов, он, скорее всего, и возьмет на себя разработку нового ПО, имея для этого полный набор инструментов и возможностей реализации. Если же своего центра разработки нет, основную роль в принятии решения будет играть кадровый вопрос и степень глобальности проекта. Небольшие программные системы могут разрабатываться как внутри компании, так и у подрядчиков, а вот с более серьезными разработками решение обычно сводится к внедрению тиражируемого ПО.
Малый бизнес отличается своей реактивностью в управлении, что зачастую приводит к дублированию одних и тех же функций разными сотрудниками наряду с наличием сотрудников, обладающих достаточно большим списком должностных обязанностей. Какое это отношение имеет к разработке ПО? Самое прямое. Компания небольшая, неофициальные новости легко распространяются, инициатива заметна, и достаточно легко выясняется, что один из «сисадминов» мало того, что и «сисадмин»-то неплохой, он еще и на машинке вышивает, вернее, на С# что-то пишет, да и в Java разбирается.
Ну а если ИТ-отдел состоит не только из системных администраторов и службы поддержки пользователей, то тут предрасположенность такой компании задействовать внутренние ресурсы в целях повышения своей конкурентоспособности за счет разработки собственного решения (не говоря о желании сэкономить на покупке имеющихся на рынке продуктов) совершенно очевидна.
Главное, чтобы костюмчик сидел
Наверное, на этом стоит остановиться и пойти разложить пасьянс с имеющимися картами.
Вот и первый расклад: средняя компания, кризис, дефицит финансов, далекий филиал с плохим каналом доступа в Интернет… Долго думать не приходится – ищем типовое решение.
Второй расклад тоже не «теорема Ферма»: маленькая компания, пара программистов, амбиции руководства, стремление все автоматизировать — однозначное указание на необходимость разработки своего решения.
Желаю вам хороших раскладов и «жирных» прикупов в бизнесе, и пусть ваш пасьянс сойдется. Ну, или пусть костюмчик сядет, как положено, независимо от места его пошива, фасона и ткани.
Опубликовано 14.04.2010