Роберт Фалковиц (Robert S. Falkowitz) основатель и главный консультант компании Concentric Circle Consulting, опубликовал в своем блоге Манифест разработчика ITSM-решений
Рынок автоматизации ITSM заполнен сотнями решений, почти неотличимых друг от друга. По сути все они – инструмент для регистрации и маршрутизации запросов, сбора статистики и генерации отчетов о поддерживаемых процессах. Некоторые доступны для пользователей. Другие поддерживают управление знаниями. Решения интегрируются в существующие корпоративные системы управления, используя различные соединения, стандартные API или прямой доступ к базам данных.
И тем не менее, персонал служб ИТ возражает против внедрения этих решений. Люди жалуются на двойной ввод данных, существенные административные издержки и слабую помощь в работе второй и третьей линий поддержки.
Любой, кто сравнит, для чего эти решения разрабатывались, и как они используются, увидит, что они немногим полезней, чем простейшая программка, которую грамотный специалист сделает за пару дней на любой платформе.
Сегодняшние средства автоматизации пытаются достичь эфемерной цели заменить высококвалифицированный персонал на менее квалифицированный, и потому – более дешевый.
Они отражают чаяния тех менеджеров, которые умеют снижать издержки, но не умеют повышать ценность! А страдают от этого пользователи, вместо помощи получающие бессмысленные вопросы от тех, кто не понимает ни собственных вопросов, ни ответов, ни смысла происходящего.
Пришло время пересмотреть архитектуру инструментов поддержки управления ИТ-сервисами и найти такие решения, которые принесут истинную ценность всем заинтересованным сторонам. Пришло время прислушаться к тем специалистам, которые используют эти инструменты в своей работе, и создать такие решения, которые им действительно нужны.
Поэтому для достижения целей
- управления услугами для получения ценности
- понимания потребностей и выполнения требований высококвалифицированных специалистов
- непрерывного повышения эффективности применения
- точного и эффективного документирования работ по управлению услугами
мы намерены придерживаться следующих принципов:
- улучшать существующие инструменты вместо того, чтобы добавлять новые
- использовать открытую модульную архитектуру для построения систем управления услугами
- модули должны объединить автоматизацию, где она возможна, с поддержкой знаний, где она необходима
- использовать открытые протоколы для облегчения интеграции различных инструментов
- использовать открытые расшряемые модели данных, основанные на стандартных онтологиях, для обеспечения получения, обработки, передачи и хранения данных по управлению ИТ-услугами.
Невозможно создать единый инструмент для управления всем аспектами ИТ-услуг. Поэтому мы призываем разработчиков ITSM-решений вместо эксклюзивных продуктов разрабатывать решения, создающие ценность в контексте открытой, гибкой архитектуры, способные донести эту ценность до всех сторон, заинтересованных в достижении целей ITSM.
С полной версией Манифеста вы можете познакомиться на странице автора.
Нам очень интересно узнать ваше мнение, возможно ли следовать этим принципам? Помогут ли они улучшить ситуацию с автоматизацией ITSM.
Некоторые точно стоит. Например, я готов полностью подписаться под следующими:
1. “Использовать открытую модульную архитектуру для построения систем управления услугами”. Важно, потому, что в этом случае заказчик может самостоятельно (или с привлечением партнеров) автоматизировать смежные области управления ИТ, а также управление не-ИТ-услугами, сокращая трудозатраты и риски за счет использования открытых, подключаемых модулей – CMDB, продуктовый каталог, управление работами, учет затрат вообще и трудозатрат в частности, согласования и т.д. Применяем на практике (см. функциональную архитектуру CleverENGINE).
2. “Использовать открытые протоколы для облегчения интеграции различных инструментов”. Открытость протоколов интеграции – единственный перспективный способ развивать решения, интегрирующие процессы поставщиков и поребителей услуг в условиях мультисорсинга. Применяем на практике.
От себя добавил бы следующе два принципа, которые мы также активно использовали (и продолжаем использовать) при разработке CleverENGINE:
1. Опираться в развитии функциональности решений на потребность заказчиков, а не на требования систем сертификации ПО. Смею утверждать, что в настоящее время потребности заказчиков являются принципиально более мощным драйвером развития, чем относительно слабо развивающиеся и вобщем-то поверхностные системы сертификации, такие как PinkVERIFY и сертификация APMG.
2. Внимательно оценивать, какие функциональные возможности следует “класть в коробку” (включать в новый релиз продукта), а какие – считать просто проектной практикой, не торопясь обобщать ее до уровня best practice. Иначе есть риск создать избыточно сложный продукт с массой редко используемых инструментов. Они будут усложнять кастомизацию, снижать производительность, путать заказчиков (что и зачем применять). Кто сомневается, поговорите с Оккамом.