Как и зачем организовывать доработки информационных систем HR-автоматизации под свои потребности
Стоит ли использовать систему, в которой уже есть все необходимые функции, или дорабатывать под свои потребности?
Михаил Протасов, М Про Системс (партнер Websoft)
Кейс. В одной организации необходимо было автоматизировать HR-процесс. До этого были автоматизированы только расчет зарплаты и кадровый учет — больше ничего. Нашли подрядчика, который заявлял, что у него все есть в коробке. Собрали обратную связь от других пользователей и стартовали проект по запуску этой платформы в компании. И потом, примерно в течение года, поняли, что категорически не хватает функциональности. А доработать все, что требуется компании, — долго, дорого и сложно. Пришлось весь проект свернуть и запускать все заново уже на другой IT-платформе.
Еще одна, совсем недавняя, история. В компании автоматизируют управление персоналом, уже есть автоматизированное обучение, дистанционное, очное и самое разное. И понадобилась отчетность, которую должны видеть как администраторы системы, так и пользователи. Стало понятно, что существующая система не позволяет легко делать доработки. В этом кейсе решение было найдено, хотя и более сложное и трудозатратное по сравнению с выбором на старте другой, более подходящей, системы.
Как можно на старте предвидеть такие ситуации?
Вот на что стоит обратить внимание:
– Количество и сложность бизнес-процессов
– Важность интеграции
– Размер организации
– Практика использования других IT-систем в организации
Чем больше сотрудников в компании, чем сложнее ее процессы, тем выше вероятность необходимости кастомизации.
Что учитывать при выборе системы?
1. Открытый код
Это очень важно. Это означает, что в можете обратиться к разным подрядчикам за доработками или дорабатывать систему своими силами. У вас есть выбор. Если у вас система с закрытым исходным кодом, то это означает, что если вы хотите сделать любую доработку, например внедрить более сложную отчётность, то у вас один-единственный подрядчик, к которому вы можете обратиться, — тот, кто ее разработал. При выборе любых решений я большое внимание всегда уделяю этому вопросу. Будем ли мы работать с открытым кодом? Сможем ли мы передать потом эти разработки от одного подрядчика к другому? Можем ли мы штатными усилиями это реализовать?
2. Количество специалистов и подрядчиков на рынке, распространенность системы на рынке
Довольно просто можно оценить, сколько есть резюме специалистов, которые могут дорабатывать систему. В нашем кейсе с отчетностью по обучению выяснилось что код был закрытый. Однако система была достаточно распространена, и существовала возможность обратиться к данным этой системы из другой, внешней: запросить нужные данные и выстроить отчёты в другом месте.
Использовать для доработок подрядчиков или штатных сотрудников?
Может быть, кого-то удивлю, но я, являясь подрядчиком, на самом деле рекомендую в довольно большом количестве случаев использовать штатных сотрудников. Почему?
Очень важна скорость: принятия решений, доработок, реакции поддержки. Наличие экспертизы внутри компании позволит с более высокой скоростью реализовать сильные проекты.
Зачем может пригодиться подрядчик?
· Помочь набрать и развить штатную команду, дать консультации.
· Когда штатных ресурсов не хватает. Например, в моменте нужно сделать большее количество проектов, но на постоянной основе нанимать специалистов нет необходимости.
· Полезно бывает второе мнение.
· Дублирование функций. Специалист может уволиться, уйти в отпуск, взять больничный. Как минимум нужны два человека, которые разбираются в проектах. Одним из них может быть подрядчик, который может подхватить, который примерно понимает что происходит в проекте.
Как обеспечить устойчивость доработок?
Как обновлять систему инфраструктуру без ущерба для кастомизации?
У нас было немало проектов, где мы именно этим и занимались: обновляли систему там, где уже были выполнены кастомизации.
В связи с импортозамещением также важно чтобы наши кастомизации продолжили работать при изменении инфраструктуры, то есть при смене операционной системы.
На что я здесь обращаю внимание:
– Максимум готовых решений
– Минимум технологий
– Качество кода и архитектуры
– Сохранение имеющихся разработок
– Документирование
Всё, что можно решить из коробки, я предпочитаю решать из коробки. Чем чаще используется стандартный функционал без каких-либо правок, без кастомизации, тем больше будет устойчивость к обновлениям и изменениям.
Если уже есть какая-то кастомизация, то я практически всегда, за очень редким исключением, предпочитаю ее сохранять. Лучше развивать то, что есть, даже если это не оптимально, даже если там недостаточно используются готовые решения. Если мы начнем всё переделывать, есть риск уйти в историю с бесконечным возвращением в самое начало. Лучше всегда сохранять уже накопленный опыт и продолжать его.
Минимизация технологий — почему это важно? Если у вас используется множество разных технологий, то при смене команды (а рано или поздно она сменится), нужно будет искать людей, которые все эти технологии тоже знают. А если у вас используется минимум технологий, то найти вам людей, которые будут дальше развивать автоматизацию, гораздо проще.
