О франкенштейнах в софте
В блоге западной компании, разрабатывающей софт для talent management, наткнулся на статью "Avoiding Frankenstein Software". Тема весьма актуальна - все больше компаний хочет иметь интегрированное решение для HR - не отдельные продукты по подбору, адаптации, обучению и оценке персонала, а что-то единое.
Соответственно заказчики ищут "интегрированное решение" особо не задаваясь вопросом о том, как оно интегрировано. Заказчик может в качестве "интегрированного" решения получить набор продуктов от одного вендора (или вендора и его пертнеров) которые написаны разными программистами и обмениваются данными через API и промежуточные файлы или получить полностью интегрированную единую платформу - т.е. один программный подукт разрабатываемый одной командой разработчиков. И это "две большие разницы".
На самом деле это очень важный вопрос - мы его выстрадали. У нас на одной программной платформе все модули кроме блока "Подбор персонала" (по историческим причинам и потому, что автоматизация подбора - отдельный, специфический рынок). Правда и этот модуль на единой технологической платформе со всей системой. И даже с этим единственным модулем у у нас возникает множество дополнительных сложностей с поддержкой совместимости версий и API. Поддержка даже двух разных интегрированных продуктов существенно усложняет тестирование и выпуск новых версий, обновление ПО у клиентов (а если их 3 или 4??). Сейчас мы меняем схему и переходим к максимально тесной интеграции подбора с остальной системой на уровне структур данных, иначе обеспечить эффективную работу становится трудно. Даже для такого небольшого модуля точек интеграции и информационных потоков (функций в API) около 20.
Мне даже страшно подумать, что было бы, если бы у нас отдельными подуктами были бы модули автоматизации оценки, вебинары, система управления контентом и т.п. Это действительно был бы неработосопосбный монстр. Или это не была бы интегрированная система.
Как с такими продуктами живут и работают западные компании, покупающие пачками компании и их продукты и интегрирующие их в свою платформу - для меня загадка.
Соответственно заказчики ищут "интегрированное решение" особо не задаваясь вопросом о том, как оно интегрировано. Заказчик может в качестве "интегрированного" решения получить набор продуктов от одного вендора (или вендора и его пертнеров) которые написаны разными программистами и обмениваются данными через API и промежуточные файлы или получить полностью интегрированную единую платформу - т.е. один программный подукт разрабатываемый одной командой разработчиков. И это "две большие разницы".
На самом деле это очень важный вопрос - мы его выстрадали. У нас на одной программной платформе все модули кроме блока "Подбор персонала" (по историческим причинам и потому, что автоматизация подбора - отдельный, специфический рынок). Правда и этот модуль на единой технологической платформе со всей системой. И даже с этим единственным модулем у у нас возникает множество дополнительных сложностей с поддержкой совместимости версий и API. Поддержка даже двух разных интегрированных продуктов существенно усложняет тестирование и выпуск новых версий, обновление ПО у клиентов (а если их 3 или 4??). Сейчас мы меняем схему и переходим к максимально тесной интеграции подбора с остальной системой на уровне структур данных, иначе обеспечить эффективную работу становится трудно. Даже для такого небольшого модуля точек интеграции и информационных потоков (функций в API) около 20.
Мне даже страшно подумать, что было бы, если бы у нас отдельными подуктами были бы модули автоматизации оценки, вебинары, система управления контентом и т.п. Это действительно был бы неработосопосбный монстр. Или это не была бы интегрированная система.
Как с такими продуктами живут и работают западные компании, покупающие пачками компании и их продукты и интегрирующие их в свою платформу - для меня загадка.
