Есть стандарт, бюджет – и никаких исключений.

Насколько жесткими должны быть корпоративные стандарты? Как их создавать, внедрять и развивать? Как преодолеть сопротивление сотрудников? Об опыте Росгосстраха рассказывает Андрей Сафонов, директор управления эксплуатации ИТ-департамента.

Intelligent Enterprise: Что было основной причиной для стандартизации ИТ-оборудования и услуг в вашей компании?

Андрей Сафонов: Разработка и имплементация стандартов в области ИТ — это часть общей деятельности по стандартизации всех бизнес-процессов, отражающая единую концепцию. Росгосстрах позиционирует себя как компанию, предоставляющую услуги единого качества по всей России. Этот бизнес-стандарт касается абсолютно всего — от набора страховых продуктов до отделки офисов. К стандартам у нас относятся очень серьезно и за их выполнением строго следят. Если вывеска на офисе филиала чуть-чуть не будет соответствовать принятой цветовой гамме, его директор понесёт суровое наказание.

Обеспечение единого качества обслуживания по всей территории страны — задача сложная, но частично она уже решена. Для подготовки специалистов существуют корпоративный университет и корпоративный колледж, действует система дистанционного обучения. Насаждавшаяся «огнем и мечом» корпоративная культура уже привилась, и новый сотрудник попадает в среду, не оставляющую ему выбора. Хотя, конечно, стандартизация в такой распределенной системе, как Росгосстрах, сложна и требует, особенно на первом этапе, много сил и много крови. Всё, что не подходит под стандарт, приходится вырубать и выкорчевывать. Иначе в большой корпорации просто нельзя.

Каков ваш подход к стандартизации ИТ-оборудования?

Подход был простой: мы стандартизировали всю ИТ-инфраструктуру так, как рекомендовано в ITIL. Кирпичики складывались в блоки, а из блоков конструировалось строение. Если говорить о кирпичиках, то, например, есть стандарт на принтерную и компьютерную технику, телефонию, на подключение коммуникаций. Так вот, принтеры мы покупаем только трех типов. Кроме того, существуют стандарты на оборудование офиса до пяти человек, до пятнадцати, до сорока, до девяноста и свыше, и в них оговариваются состав и характеристики устройств. Потребности в технике определяются характером работы персонала, для каждой должности определено, какое оборудование положено для работы. Скажем, сотрудникам отдела продаж полагается один ПК на троих, на офис из пяти человек — один телефон. В результате при известных нормативах рассчитать состав необходимого комплекта для вновь открываемых офисов очень легко. При этом все закупки техники централизованы, и новые офисы получают готовые комплекты оборудования из Москвы.

Надо сказать, что стандарт на оборудование у нас очень жесткий. На все письма типа «прошу разрешить мне самостоятельно купить...» ответ всегда один: «Нет». Самостоятельное приобретение техники дешевле точно не будет, проще и быстрее — возможно, но только для тех, кто покупает. Ведь службе эксплуатации потом придется разбираться с проблемами, возникающими в удаленном офисе из-за того, что кто-то где-то что-то не то купил. Поэтому любое отклонение от стандарта тут же завалит нам уровень сервиса.
Не менее жесткие стандарты приняты на серверы нижнего уровня, которые применяются в местных офисах для электронной почты и т. п. А все «тяжелые» решения, централизованные приложения (мы используем только такие) и всё нужное для их поддержки оборудование размещено в едином центре обработки данных.

Кто разрабатывал стандарты на оборудование и как проходило их утверждение?

Стандарты разрабатывало управление эксплуатации департамента информационных технологий. Занимались мы этим год, за это время накопился опыт и статистика. Мы оценили, какие у нас есть ИТ-сервисы, на каком оборудовании мы сможем их обеспечить и как их лучше структурировать. Включенной в стандарт техники для покрытия потребности на местах хватит лет на семь, а масштабирование по мере роста бизнеса мы проводим в центре. Разумеется, стандарты приходится периодически обновлять: развивается бизнес, появляются новые услуги, которые мы не можем реализовать на базе стандартов, принятых два года назад. Например, для организации диспетчерских центров в региональных дирекциях в стандартное обеспечение здания дирекции включен цифровой поток Е1.

Разработанный стандарт утверждается долго, ведь его нужно согласовать со всеми функциональными подразделениями. Затем документ выносится на правление, где он принимается без особых проблем, потому что все члены правления его уже одобрили лично. В результате стандарт приобретает силу закона. Однако допускаются и отклонения, если появляются к тому основания. Например, в некоторых регионах нам удалось заключить очень удачные договора с провайдерами телекоммуникационных услуг просто потому, что качество связи там существенно выше, чем в среднем по стране. Содержать выделенные каналы оказалось дешевле, чем подключаться по коммутируемой линии, проложенной по стандарту, и появилась возможность объединить местные офисы в региональную корпоративную сеть с лучшим сервисом, чем мы рассчитывали.

Конечно, мы этим воспользовались, раз удалось обеспечить качественный сервис за разумную цену. Вот в таких случаях, когда понятно, что не выходя за пределы бюджета имеется возможность получить больше, чем при жестком следовании стандарту, мы и идем на отклонения. Как правило, при этом предполагается, что в будущем всех удастся подтянуть к новому уровню. Но если отойти от стандарта не разрешено, то сколько бы ни бился руководитель локального офиса, сколько бы он ни требовал, например, мобильные телефоны для каждого из своих сотрудников, он ничего не получит. Во всяком случае от ИТ-службы. Есть стандарт, есть бюджет — и никаких исключений. При этом, разумеется, никто не мешает ему идти к начальству и выбивать дополнительные бюджеты, хотя, как правило, это маловероятно.

Замечу, что сейчас мы пользуемся двумя описаниями стандарта. Наш «внутренний» стандарт опирается на сервисный подход, имеет вид дерева. «Внешний» (по отношению к ИТ-отделу), который используют финансовая дирекция и другие управленческие структуры компании, оперирует не сервисными категориями, а финансовыми. В нем все возможные комплектации представлены в зависимости от размера офисов и их функциональности. По собранным в этом документе таблицам удобно делать финансовую оценку при комплектации новых офисов. Правда, подход, основанный на сервисах, более точен и позволяет учесть все нюансы. Ведь офис на 15 человек может оказаться и простым агентством, и малой дирекцией, где разный функционал и разные потребности. Но так как финансовые службы входить в такие детали не хотят, мы просто снабжаем их калькуляцией для офисов разных типов. Для бюджетной оценки этого вполне достаточно, когда же дело дойдет до реальных денег, то все расчеты будут сделаны на основании реальных предложений от поставщиков и интеграторов, а предложения будут написаны в соответствии с принятыми стандартами на оборудование.

Как вы рассчитывали потребности в технике и ее характеристики? И часто ли пересматриваете эти нормативы?

Все идет от сервисов. Допустим, есть сервис — система операционного учета договоров страхования. Чтобы она работала, в офисе, из которого должны поступать договоры в центральную базу, нужен ПК. Производительность его известна: один операционист не может ввести более ста договоров за рабочий день. У агентства есть план заключения договоров, значит, сразу можно оценить, сколько операционистов и сколько ПК им нужно. И так далее — на каждый сервис расписан норматив.

Первая версия стандарта появилась у нас в 2003 году. Постепенно накапливаются изменения, и мы уже второй раз пересматриваем его с тех пор и сейчас готовим третью версию. Это связано с внедрением ведомственной телефонии, что сильно меняет требования к офисам, ведь к ним подводится собственный канал. Или, например, начинается внедрение системы учета договоров медицинского страхования — понятно, что под нее потребуются дополнительные мощности. И тут, видимо, неизбежны отклонения от принятого стандарта: офисы, занимающиеся медицинским страхованием, скорее всего будут выездными, при больницах, поэтому, возможно, стоит купить их сотрудникам ноутбуки. Вот и получится изменение стандарта в связи с появлением нового вида услуг. Это наша задача на следующий год.

Как был проведен переход на стандартное оборудование? С какими проблемами вы здесь столкнулись?

Очень просто: если какой-то тип оборудования по стандарту поставляется централизованно, то его самостоятельное приобретение запрещается. А ранее приобретенная техника, не соответствующая стандарту, постепенно умирает и через три года с высокой вероятностью меняется на стандартную. На самом деле в большинстве случаев нам столько ждать не пришлось, поскольку оборудование было старым, а кое-где его не было вообще. Техническая оснащенность региональных подразделений в 2003 году за редкими исключениями была очень слабой. Речь шла не о том, чтобы что-то менять, а о том, чтобы наконец нормально оборудовать офисы.

Замечу, что мы пошли по пути применения терминальных решений и убедились в правильности этого подхода. Обслуживание техники при использовании терминалов удаленного доступа к централизованному сервису существенно менее трудоемко, чем обеспечение работы распределенных локальных сервисов. Самое главное — построить коммуникации. Это непросто, но реально. Ко всем крупным офисам у нас проложены собственные сети (на основе аренды канальной мощности у провайдеров и организации VPN — более сотни точек, к концу года их будет триста). Остальные офисы пока работают через Интернет, и этого достаточно. Ведь в нашей системе транзакций нет, а все бухгалтерские сервисы действуют только в закрытом сегменте корпоративной сети.
Если приложения централизованные — на мой взгляд, нет смысла что-то держать на местах, кроме терминалов. Если же есть какие-то местные, локальные самописные приложения, путь только один — уничтожать.

Даже в том случае, когда они объективно лучше?

Честно скажу: вполне возможно, что локальное приложение может быть лучше, чем централизованное в данной области. Просто потому, что в нём учтены местные условия, уже наработан некоторый опыт. И все равно его следует заменить на централизованную систему, это проверено четырёхлетней практикой. Каковы бы ни были преимущества локального приложения, они не окупают проблем, возникающих при его эксплуатации. Локальные приложения не поддаются стандартизации и привязаны к их создателям, чего категорически нельзя допускать в большой компании. А кроме того, ИТ-приложения создаются для обслуживания бизнеса. Если бизнес централизован и стандартизирован, то поддержка локальной версии теряет всякий смысл, это просто двойная работа. Поэтому у руководителя любого местного офиса, где используется какое-то свое, пусть идеально отточенное и чудесное приложение, нет выбора: ему дается определенный срок, чтобы его уничтожить и перейти на стандартные средства. Не перейдешь — будешь серьезно наказан. И никаких исключений.

Сложности работы в режиме удаленного терминального доступа состоят в том, что необходимо наладить коммуникации в условиях ограниченных финансов. В одном месте, например, мы держим 200 человек на канале 512 кбит/c. При такой нагрузке ни один провайдер не может гарантировать качество. Но это проблема недостаточного финансирования, так что в следующем году попробуем исправить дело. После четырех лет работы в Росгосстрахе я точно знаю, что при необходимости можно построить канал в любую точку России. Другой вопрос, во сколько он обойдется, особенно его содержание.

Конечно, для перехода на терминальные решения потребовалось переобучение ИТ-специалистов, но это не составило проблемы. Основная нагрузка в таких решениях ложится на центр, и если в нем все организовано без особых ляпов, сложностей не будет. Не было их и с пользователями. Все служебные данные с пользовательских машин были перенесены в централизованные приложения, а что не осталось игр, книг и личных баз данных — так это только хорошо. Если на рабочем ПК лежат посторонние материалы, сотрудник будет немедленно наказан. А если хранятся данные о клиентах, договора или иные служебные документы, которые должны быть в централизованной системе, — будет наказан тем более. Требования жесткие: все данные должны быть в общей базе. И точка.
Единственное исключение может быть сделано в том случае, если для каких-то типов данных еще нет централизованного приложения. Возможно, такое приложение еще только пишется, но всё равно все материалы должны быть перенесены на центральный файловый сервер. Подобная ситуация у нас недавно возникла с фотографиями. Было решено, что агенты должны фотографировать объекты страхования. Появились массивы фотоизображений, а средств для работы с ними еще нет. Их нельзя заводить в общую базу договоров, поскольку она тогда станет совершенно неподъемной, здесь нужно отдельное приложение. По разным обстоятельствам приложение не было разработано своевременно и делается только сейчас, поэтому фотографии временно хранятся в файловых архивах.

Насколько полно вам удалось реализовать требования стандартов?

Что касается оборудования в офисах и обеспечения деятельности тех систем, для которых уже запущены в промышленную эксплуатацию централизованные приложения, то стандарты выполнены на 90%. ИТ-сервисы формализованы и приведены в соответствие с требованиями ITIL не более, чем на 15%. С точки зрения идеологии сделана примерно половина, а с точки зрения формализации — намного меньше. Это действительно тяжело. Нужно создать массу документов, все зарегламентировать. Постепенно мы эти документы создаем, но не торопимся. Сейчас ситуация с ИТ в Росгосстрахе такова, что мне как руководителю службы эксплуатации удобно ею управлять, а моему руководителю удобно меня контролировать.

А если еще поднять уровень стандартизации? Насколько стандартизирована собственно деятельность подразделения эксплуатации?

Дальнейшая стандартизация осложняется спецификой нашей работы. Дело в том, что традиционно принятые методы организации деятельности и стратегического планирования не вполне ей соответствуют. Проще говоря, классические методы организации деятельности, а именно метод проектного управления, не рассчитаны на управление эксплуатацией. В Росгосстрахе все ведущиеся в различных подразделениях проекты контролирует единый проектный офис. Пока задачи, которые стояли перед нами, вписывались в классическое определение проекта (то есть имелись четко обозначенные задачи с известным временем их начала и завершения), проектное управление работало. Но оно не приспособлено для управления текущей деятельностью, которая собственно и составляет основную деятельность службы эксплуатации. Фактически мы несколько лет работали как служба внедрения и только сейчас начинаем переходить в режим нормальной эксплуатации.

Методы проектного управления перестают работать, потому что принятые там критерии оценки не годятся для текущей деятельности. Вообще говоря, объективный показатель успешной работы службы эксплуатации найти очень непросто. Я бы сказал, что эксплуатация поставлена идеально, если никто никогда о ней не вспоминает. Просто всё, что должно работать, — работает. И как в таком случае оценивать успешность деятельности службы эксплуатации в рамках понятий управления проектами, какие поставить цели и сроки их достижения? А ситуации в эксплуатации бывают совершенно непредсказуемые, и жесткие методы планирования перестают работать в быстро меняющихся условиях.

Поэтому служба эксплуатации начинает отходить от принятого в проектном управлении метода постановки целей и поиска средств для их достижения и переходит на другой способ управления: необходимо обеспечить условия для безотказной работы всех имеющихся в эксплуатации сервисов. На практике это означает регулярное, последовательное и аккуратное выполнение множества не слишком значительных рутинных задач.

Основная трудность в организации эксплуатации больших и сложных систем заключается в огромном количестве вариантов того, что может когда-нибудь произойти. Поскольку нет никакой возможности на этапе приемки системы предусмотреть на будущее все вероятные события, то нет и возможности дать последовательную инструкцию по выходу из нештатной ситуации. Поэтому задача руководителя службы эксплуатации заключается в следующем.

Во-первых, организовать работу так, чтобы все штатные операции выполнялись своевременно и правильно. Этот вопрос решается введением регламентов работ и инструкций. Как правило, при вводе в промышленную эксплуатацию новой системы никаких регламентов не существует, их надо создавать.

Во-вторых, максимально предусмотреть действия службы в нештатных ситуациях. Это тоже вопрос регламентации, но уже более сложный. Очевидно, что как минимум следует организовать работу по регулярному резервному копированию всей имеющейся в системе информации, и эта задача кажется очень простой только до того момента, когда из сделанных резервных копий информацию потребуется восстановить. Этот вопрос можно долго развивать, я же ограничусь упоминанием о человеческом факторе: уход квалифицированного специалиста тоже может стать нештатной ситуацией, если изначально не была предусмотрена взаимозаменяемость специалистов в службе эксплуатации.

Наконец, в-третьих, обязательно нужно иметь понятие о порядке взаимодействия и взаимозависимости находящихся в эксплуатации систем.

Для работы службы эксплуатации, на мой взгляд, самой подходящей является технология структурирования задач, наиболее наглядно реализованная в методике MindMap. Ничего нового в таком подходе нет, это просто один из способов структурирования деятельности: составляется список задач и группируется по уровню значимости, выделяются ресурсы, задачи разбиваются на подзадачи.

Особенность заключается в том, что для службы эксплуатации задача повышения производительности труда стоит гораздо ниже задачи обеспечения необходимого качества. В силу этой особенности предъявляются несколько иные требования к планированию времени. Нельзя допустить, чтобы сотрудники были перегружены количеством выполняемых задач, потому что если в проектной работе это приведет к увеличению сроков исполнения, то в эксплуатации такая перегрузка ведет к отказам системы; и в то же время не имеет смысла планировать недогруженность сотрудников. Самый простой способ решения этой проблемы — запускать часть работ в фоновом режиме: появилось время, и сотрудник переключился на несрочную задачу.