Статья навеяна опытом взаимодействия с бесконечным количеством специалистов ИТ отделов заказчиков, а также опытом разработки собственных программных продуктов Enterprise уровня и их дальнейшего внедрения в инфраструктуру заказчика и приземление на бизнес-процессы с последующих тиражированием. В общем, мы не играемся в ИТ, а занимаемся этим профессионально скоро уже 20 лет. Поэтому приступим к препарированию вопроса выбора программ для бизнеса.
Но обязательно нужно сделать оговорку - все, описанное ниже, справедливо для выбора нового класса программного обеспечения (ПО), которое еще не использовалось в компании. В случае замены одного ПО на другое процесс выбора, действительно, может свестись к тестированию необходимого функционала, список которого можно получить от текущих пользователей программы, для которой ищется замена.
Проблема выбора программы для цифровизации бизнес-процессов стоит остро не только в строительстве, но и в любой другой сфере деятельности. Компании заказчики ищут наиболее подходящий по соотношению "цена-качество" программный продукт. При этом то самое "качество" из формулы "цена-качество" формируется из списка требований (в основном функциональных) внутри компании. К сожалению, эти требования чаще всего не согласованы с целями и задачами внедрения программного продукта.
В результате, закладывается бомба замедленного действия, из-за которой компании покупают не нужные или неподходящие им продукты. Тратят деньги и драгоценное время в пустую. За последние 10 лет мы наблюдали не раз как крупные компании, обладающие большими ресурсами, делали неправильный выбор и буксовали иногда по 5 лет на одном месте - бизнес-процесс оставался в том же состоянии, что и до внедрения программы.
В статье разберем классический и самый распространенный на сегодняшний день подход в выборе ПО и сравним его с более эффективным и прагматичным предлагаемом мной подходом.
Классический подход выбора ПО
Под классическим подходом будем понимать превалирующий на сегодняшний день подход компаний к выбору программного обеспечения (ПО), при котором в ИТ-отделе назначается специалист ответственный за подбор программного продукта. Далее этот специалист составляет критерии сравнения через анализ рынка и общение с потенциальными пользователями.
Часто бывает так, что запрос на программу идет непосредственно от подразделения компании (отдела, департамента, управления). С рекомендациями конкретного ПО. В данном случае есть определенный позитивный момент, заключающийся в том, что сами пользователи хотят цифровых изменений и будет меньше проблем с саботажем при внедрении. Но все еще остается вопрос к самому подходу определения критериев выбора. Может показаться, что я сгущаю краски, но на практике слышал аргумент "мне больше нравятся синенькие кнопочки, поэтому все же остановлюсь на таком-то продукте".
Последовательность шагов выбора ПО при классическом подходе
- Составим критерии сравнения
- Определим шорт-лист кандидатов среди разработчиков программ
- Запросим у вендоров заполнить анкету соответствия
- Проведем демонстрации и уточняющие встречи
- Выведем итоговый балл по результатам заполнения таблицы и демонстрации, по которому и выберем нужную программу
Казалось бы выглядит все стройно и логично, но дьявол кроется в деталях. А детали начинаются с самого первого пункта "Критерии сравнения". Давайте включим критическое мышление и зададим себе вопросы "Почему именно этот критерий важен?" или "Какой критерий важнее первый или второй?" или "А для кого важнее?" или "Достаточно ли наличия описанного в критериях функционала для того, чтобы трансформировать бизнес-процесс в целевое состояние?".
В 99% случаях ответа на эти вопросы вы не услышите. Потому что на первоначальном этапе покупка программы стала самоцелью. Никто не подумал, а что будет происходить после покупки. Мне возразят - "Что за ерунду ты несешь? Все же понятно, после покупки будет обучение пользователей. А дальше?.. Дальше непосредственная работа. Программа то простая". Такие диалоги происходят вслух или в голове собеседника.
К сожалению, программа сама себя не внедрит и на одном обучении далеко не уедешь. Нужен фундамент целей и задач бизнеса. Но о внедрении мы поговорим отдельно. Сегодня обсуждаем процесс выбора ПО.
Могу еще отдельно разобрать каждый из последующих шагов. О том как вендоры могут проставить "плюсики" напротив каждого критерия, потому что интерпретировать его можно в свою сторону. Так и о том, что сотрудники компании заказчика могут "топить" всех конкурентов, чтобы выбрать понравившегося им. То есть субъективность проявляется со всех сторон и качество выбора в итоге страдает.
Предлагаемый подход
А как правильно? С одной стороны ничего нового вы не услышите, с другой стороны почему-то очевидное оказывается сложно выполнимым.
Нужно идти от ЦЕЛЕЙ, а целью может быть трансформации бизнес-процесса, т.е. приведение его к целевому состоянию. Таким целевым состоянием может быть как схема взаимодействия участников бизнес-процесса, так и целевые показатели эффективности работы. Например, снизить срок сдачи работы с 2 месяцев до 2 недель или сократить количество просроченных предписаний с 30% до 5%. И так далее.
Как только появляется описанная цель, становится понятно, что зачастую она не решается только покупкой и внедрение программного обеспечения. А приобретаемое ПО начинает оцениваться не по критерию наличия того или иного функционала. А по критерию - "позволит ли оно достичь поставленной цели по трансформации бизнес процесса". И по ходу отсмотра программных продуктов начинает выясняться, что у одного решения функционала больше, но оно менее подходит, чем другое с более скромным, но позволяющим лучше закрывать поставленные задачи.
Например, на практике мы видели как компании выбирали программный продукт по количеству функций и решающим стала функция работы с BIM моделью. Как потом выяснилось, компания была не готова работать на строительной площадке с BIM моделью, а остальной функционал оказался неудобным и неприменимым. В результате, компания вернулась к решению, у которого нет функции работы с BIM моделью, зато необходимый именно этой компании функционал реализован.
Эффективная последовательность шагов
- Описываем целевое состояние бизнес-процесса, к которому хочется прийти, внедрив программу
- Определяем ключевые разносторонние критерии, которые позволят достичь обозначенной цели, включая требования к компании поставщику
- Проводим встречи и другие активности для проверки этих критериев
- Останавливаемся на варианте, который позволит достичь цели. Если вариантов несколько, оцениваем наиболее выгодный по совокупной стоимости владения
Про важность постановки цели подробно написано выше. Отдельно же хочется остановится на важном моменте, который может ускользнуть из внимания - совокупная стоимость владения. Из чего складывается стоимость: лицензии, услуги по обучению, услуги по внедрению, услуги по поддержке, услуги по развитию информационной системы, услуги по интеграциям с другими корпоративными информационными системами. Также стоимость может быть увеличена в случае потребности в удовлетворении корпоративных требований по информационной безопасности, требований по интеграции с государственными системами, потребности в закупке корпоративных мобильных устройств, потребности в закупке дополнительного серверного оборудования.
Неочевидные критерии для сравнения программных продуктов
В конце статьи справочно приведу некоторые неочевидные критерии, на которые стоит обратить внимание. Они общие и не затрагивают функциональную составляющую программ.
- ВОЗРАСТ КОМПАНИИ, время её активной работы на рынке предоставления услуг и продажи программного продукта. Рекомендация - не меньше 3 лет, лучше 5 и более.
- ОПЫТ ВНЕДРЕНИЯ программы для цифровизации схожих процессов у схожих компаний.
- ОПЫТ АТТЕСТАЦИИ по ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ у крупных компаний схожих или больше вашей
- ОПЫТ ИНТЕГРАЦИИ с ДРУГИМИ ИТ-СИСТЕМАМИ - не наличие API, а именно опыт и количество систем, с которыми удавалось "подружиться"
- РОССИЙСКАЯ ЮРИСДИКЦИЯ и МЕСТОНАХОЖДЕНИЕ СЕРВЕРОВ
- НАЛИЧИЕ МЕТОДИКИ ВНЕДРЕНИЯ и либо собственного отдела внедрения у вендора, либо сертифицированного партнера
- НАЛИЧИЕ ОФФЛАЙН РЕЖИМА у мобильных приложений
Выводы
При изменении фокуса при выборе ПО с "кнопочек" и "функционала" на целевое состояние бизнес-процесса подход меняется в корне и закладывается фундамент для успеха проекта по цифровизации. Оставаться в старой парадигме невыгодно и даже вредно. Теряется драгоценное время и тает рентабельность строительных проектов. Поэтому призываю всех смотреть на вопрос выбора ПО более критично и системно. И не составлять сравнительных табличек почем зря. Простите меня все, кто потратил не один день за этим занятием (сами такими были).
Желаю всем правильно и системно подходить к выбору программного обеспечения для трансформации бизнеса и меньше ошибаться.