Кроме заявленных результатов, на наших ревью и на ежемесячных встречах нужно показывать ещё и предысторию этих результатов. Например, если мы говорим о том, что у нас есть такой-то уровень надежности, то смотрим в разрезах по подразделениям, если есть какие-то сомнения, то в разрезах по дням. И когда происходит столкновение лбами между, допустим, директором филиала, который говорит: «У меня весь филиал неделю стоит!» и IT-сотрудниками, которые говорят: «Да, ну, ребята, вы чё, у нас высочайшая надежность системы, никаких сбоев не было!», тогда под присмотром генерального директора эту ситуацию начинают изучать и доказывать друг другу, кто из них всё-таки больше прав. А для этого используют статистику и начинают выяснять, что и те погорячились, допустим, рассказывая о высочайшей надежности, ну, и у этого не неделю стоял весь филиал.
До драк не доходит. В данной ситуации мы можем двумя способами воспользоваться. Во-первых, это генеральный директор, который затребует у них всех статистику и примет своё, безусловно, мудрое решение. Если мы будем подозревать о том, что там с показателями творится какое-то хитрое или кислое дело, то туда может быть направлено наше контрольно-ревизионное управление, которое поднимет все логи. Вот это будут как раз те самые люди без масок, но с добрыми улыбками на лицах. Они соберут всю эту статистику и скажут, что по математике что-то не бьется.
Здесь важно понимать, что управление неприятностями, которые уже случились, – это управление постфактум, когда можно найти виновного, вознаградить его очень сильно, чтобы ему стало жутко стыдно и так далее. Ситуация организована таким образом, что пользователи сами начинают беспокоить ребят, как только что-то проваливается. Потому что пользователи знают критичные участки, которые не работают, либо те, где можно подождать. И не всегда по пустякам беспокоят, нету звонков типа «Вы знаете, не могу найти мышку, как она там движется». Их всё реже и реже беспокоят. И получается, что на надежность информационной системы положительное влияние оказывают уже и сами пользователи. Есть практика такая: процесс выставлен, они бегут и бегут – помогите, спасите.
То есть это технология, и она только выдает готовый результат. То, что касается вопроса, кто влияет на бюджеты центра затрат и может ли центр прибыли влиять – безусловно, может. Так как центр прибыли в организационной структуре – это генеральный директор, потому что он отвечает перед собственниками за разницу между доходами и затратами, естественно он вместе с финансистами как-то мудро выделяет деньги на IT. Когда нам нужно что-то развивать (это больше связано с инвестициями в IT) мы обращаемся в центр инвестиций, который находится в головной компании, оттуда запрашиваются инвестиции. Поддержание IT-системы ведется на уровне центра затрат. Естественно, раз предусмотрен бюджет с определенными параметрами, то как только начинают выходить за пределы этого бюджета, нужно обращаться к вышестоящему руководству и владельцу бюджета. Я ответил так, как я вопрос понял.