Intelligent Enterprise: Прежде чем говорить о различных прикладных ИТ-сервисах по существу, хотелось бы понять базовые принципы той модели, в соответствии с которой работает «Электронная Москва»…
Алексей Алексеев: Говоря о модели, наверное, можно сразу назвать ключевое слово SaaS или, ориентируясь на вполне уже сложившуюся трактовку данного термина, иметь в виду предоставление прикладного функционала информационных систем в соответствии с сервисной моделью. Да, мы ориентируемся на SaaS и на тесно связанные с этой концепцией облачные вычисления. Но когда пытаешься выстроить модель предоставления информационных сервисов, взаимодействуя с конкретными заказчиками, имея дело с конкретными ИТ-функциями в конкретной среде, сразу понимаешь, что этого определения недостаточно. По крайней мере становится ясно, что SaaS-модель в принципе может работать как некий полуфабрикат, а может функционировать на более высоком уровне, для чего, в свою очередь, нужна несколько более детальная технологическая проработка и иные организационные принципы взаимоотношений с заказчиком. Отсюда, по сути, следует, что у нас есть некоторая классификация SaaS-предложений.
Первая категория систем не предполагает программную доработку под задачи заказчика, а связана исключительно с настройкой. Примером может служить сервис электронной почты, который, безусловно, требует настройки, равно как и обслуживания. Здесь необходимо соблюдение SLA, и со стороны провайдера должны выполняться те процедуры, которые напрямую ассоциируются с эксплуатацией сервиса. Если, скажем, тот или иной пользователь покинул организацию, соответствующий аккаунт технически должен быть удален из директории, т. е. кроме классических сервисов мы предоставляем услуги по ведению справочников, расширенной технической поддержке и обучению пользователей и таким образом действительно снимаем заботу о работе сервиса с заказчика.
Однако на практике большинство востребованных ИТ-сервисов все-таки связано с доработкой, и они составляют вторую категорию наших предложений. Здесь примером является система электронного документооборота (далее будем называть её ЭДО) города Москвы.
По сути ключевым моментом подобных систем является именно возможность совершенствования функционала, а значит, непрерывного ведения разработок. И поскольку это главное, то сама разработка и контроль за этим процессом должны быть организованы предельно технологично. У нас жизненный цикл приложений (начиная от сбора требований и заканчивая вводом необходимого функционала в эксплуатацию) организован с помощью инструментов класса ALM (Application Lifecycle Management) компании HP.
В строгом смысле контроль за разработкой не является обязанностью сервис-провайдера. Его можно отдать и заказчику, если у того есть соответствующая компетенция. Однако в нашем случае разработка ― сложный процесс. Отдельные части проектов могут вестись независимо, и принимать их тоже надо отдельно. Некоторые функции, разрабатываемые для одних заказчиков, впоследствии могут успешно использоваться другими. Поэтому мы решили для себя, что наиболее оптимально самим накапливать экспертизу в реализации всего жизненного цикла создания ПО и предоставлять заказчику комплексный сервис, включая услуги по развитию программного функционала ИТ-услуг.
Какие организации привлекаются к использованию сервисов «Электронной Москвы»?
Можно сказать, что сервисами, которые мы предоставляем, пользуются все. И чиновники, и коммерческие организации, и жители. Это можно продемонстрировать на примере электронного документооборота города Москвы. В систему вовлечены все 25 тысяч работающих на сегодняшний день московских чиновников, сюда же входят подведомственные организации (около 25 тыс. пользователей) и коммерческие компании, которые оказывают городу услуги, ― уже зарегистрировано более двух тысяч таких компаний. Важное отличие от универсальных средств организации электронного взаимодействия в данном случае состоит в том, что сообщению всегда можно придать статус юридически значимого документа.
Сегодня технологии B2B-, B2G- и B2C-взаимодействия пытаются тесно привязать к облачной концепции вычислений и SaaS-сервисам. Какие преимущества с позиций вашего опыта они дают при реализации всех этих технологий электронных коммуникаций?
Я думаю, в наших типичных сценариях взаимодействия переплетаются все названные вами шаблоны, а SaaS и облачные технологии как раз позволяют их гибко консолидировать, что часто бывает весьма критично для решения конкретных задач. Запрос, поступивший от жителя после оперативной обработки службой модерации, поступает в систему ЭДО Москвы и по сути сразу становится поручением чиновнику. Он в свою очередь может дать поручение обслуживающей организации исправить ситуацию (например, восстановить подсветку в табличке с номером дома). Организация, быть может, согласно регламенту осуществляла проверку только что, и все было в порядке. Однако, что называется, сигнал поступил, и оперативную информацию она получает через ЭДО. У данной компании есть SLA, в соответствии с которым она и действует.
Но компания и сама может инициировать запрос, если по каким-то причинам ей, скажем, вовремя не заплатили деньги. И всё это делается через ту же самую систему ЭДО.
В случае каких-либо более сложных сервисов, требующих вовлечения нескольких коммерческих соисполнителей и синхронизации их работ, с помощью системы ЭДО они могут самостоятельно наладить между собой оборот тех или иных документов. В том числе юридически значимых, требующих квалифицированной электронной подписи. Такова реальная практика уже на сегодняшний день.
Облачные технологии обладают еще и тем преимуществом, что по определению позволяют формировать некий централизованный информационный ресурс, что в ряде чисто практических ситуаций очень важно. Например, легко можно найти адреса электронной почты вовлеченных в ту или иную работу чиновников либо сотрудников компаний. Ведется реестр подключенных к ЭДО коммерческих организаций, а значит, их тоже можно быстро найти, если надо оперативно организовать какие-то работы с их участием.
Помимо самого электронного документооборота и напрямую привязанных к нему сервисов (скажем, электронной подписи) в решении задач электронного взаимодействия, объединяющего власти, чиновников, сотни коммерческих организаций и жителей Москвы, очевидно, должны быть задействованы и иные системы. Что вы могли бы сказать по этому поводу?
Об одной из таких систем – системе управления жизненным циклом программного обеспечения (ALM) я уже сказал. Поскольку разработка новых прикладных сервисов и поддержка их качества – наша задача, ALM позволяет транслировать запросы пользователей в процессы жизненного цикла ПО, ориентированные на разработчиков-профессионалов.
Еще один очень важный для нас класс ПО ― системы сервис-менеджмента. Более всего они известны в контексте темы оптимизации работы внутренних ИТ-подразделений компаний. Существуют, скажем, запросы на выполнение определенных работ, которые нет необходимости проводить через канцелярию со всей атрибутикой входящих и исходящих документов. Для регистрации таких запросов ЭДО является избыточным и дорогим инструментом. Все подобные вещи мы организуем с помощью продукта HP Service Management (HPSM), пытаясь применительно к задачам управления городом наследовать такие известные понятия сервис-менеджмента, как, например, управление инцидентами или управление проблемами.
Благодаря этому направлению автоматизации помимо формирования запросов мы имеем возможность следить за регламентом деятельности, за соблюдением SLA тысячами исполнителей, легко формировать отчеты произвольных типов.
Исполнители в свою очередь при планировании работ могут ориентироваться на предыдущие практики реализации похожих проектов, оценивая, какие ресурсы потребуются им для определенной деятельности и каких специалистов им для этого необходимо привлечь. Все подобные данные накапливаются в системе HPSM. Конечно, ее нельзя отождествлять со специализированными управленческими системами, позволяющими детально моделировать и обсчитывать самые разные варианты калькуляции затрат, но на практике это далеко не всегда бывает нужно.
Вообще же системы ALM, HPSM и инструменты BI для нас являются своего рода единой платформой, позволяющей организовать замкнутый цикл работы с информацией, в том числе при взаимодействии с нашими партнерами. Если говорить языком практических сценариев, то запросы, реакция на них и данные множества отчетов могут анализироваться системами BI, что позволяет, скажем, выявить типовые, существующие на определенный момент времени «болевые точки» в оказании сервисов. На сегодняшний день аналитиками службы технической поддержки уже разработано порядка сотни типовых отчетов, которые можно получать как через HPSM, так и по подписке по электронной почте. В частности, с их помощью можно понять, кто из исполнителей ― неважно, где он работает, ― не справляется со своими обязанностями. Одновременно есть возможность четко сформулировать требования к совершенствованию ряда ИТ-сервисов, чтобы транслировать их в ALM-систему. Последняя, как я уже сказал, позволит адекватно организовать разработки, связанные с совершенствованием ИТ-услуг, и затем передать их в эксплуатацию. А далее нужно снова контролировать процесс оказания услуг и искать пути к его дальнейшему улучшению. Собственно это и есть тот замкнутый цикл, о котором я уже говорил. Но замкнутый цикл не означает, что мы остановились в развитии. Мы развиваем сервисы, углубляем их интеграцию, постоянно ведем поиск эффективных решений. Например, HPSM позволяет не только выявлять ошибки приложений, но и создавать курсы по обучению пользователей.
