Сталося так, що призначили мене начальником ІТ відділу. У бутність того часу я обіймав посаду начальника групи розробки та експлуатації електронних інформаційних систем, і, завдяки тому що вся група на той момент складалася з однієї людини - мене, я легко з нею управлявся. Проте ж мої раціоналізаторські таланти не пройшли повз керівництво, і, в період реорганізації компанії, групу ІТ (з парою адмінів і начальником) вирішили вивести з під відділу інженерно-технічного департаменту і зробити окремий ІТ відділ. Мене ж у свою чергу вивели з відділу забезпечення якості (не питайте, що там робила група РЕЕІС) і зробили начальником цього «новоствореного» відділу. З одного боку, це тішило самолюбство. З іншого боку, крім тієї роботи, яку я виконував, мені ще доведеться піклуватися про килимки для мишок, і «у мене курсор не блимає»... Відмовитися теж було не особливо можливо. Власне, мені просто поклали на стіл наказ про те, що тепер я начальник. Припускаючи, що кількість роботи від цього призначення не зменшиться, я повідомив начальство (яке, мабуть, думало, що я нічим не займався), що керувати групою у мене скоріше всього часу не вистачить, вистачить тільки керувати. Начальство махнуло рукою - для нього мабуть різниці не було.
Вступивши на посаду, я швидко звільнив обох адмінів, залишивши більш кмітливого начальника групи, і замість двох не дивно розторопних найняв одного, як мені тоді здавалося більш розторопного. Все, бінго, я начальник, управлінські рішення прийняті, залишилося два чудових працівника, кмітливих і мотивованих. Якщо що потрібно буде допомогти - телефонуйте, завжди допоможу. А зараз дозвольте - ви розумні дорослі люди, займайтеся своєю роботою, а я пішов допрацьовувати свої корпоративні системи.
Так все і йшло деякий час. Мені здавалося, що я керую процесом, і на піку складнощів, коли моїм співробітникам необхідна допомога, приходжу як супермен-рятувальник, а рутинно все якісно і здорово працює само по собі. Їм здавалося - начальство далеко, ми представлені самі собі і нехай так буде. (Партисипативний стиль управління, ога..)
Через якийсь час мене стали смикати з будь-якого приводу. Мережа не підключається, ворд не відкривається, картридж не змінюється, і мишка не їздить. Ви ж з ІТ відділу? Кому яка справа, що начальник - мені працювати треба! Особливо пригнічував той факт, що ті, хто дзвонив, вже один або кілька разів зверталися в службу підтримки, але адміни забували про них, оскільки виконували якусь іншу роботу або просто забивали. Навіювання і наганяї адмінам у цій ситуації зрозуміло марні. Почав назрівати момент, коли стала необхідна класична черга заявок в ІТ відділ.
Керівником ІТ я був новоспеченим і поняття не мав про ITSM, однак, як Хосе Аркадіо Буендіа, який відкрив, що земля кругла як апельсин, я так само приблизно собі прикинув, як повинна бути організована служба заявок в ІТ. Після певного тугодум я намалював коротенький процес.
Заявки були організовані в системі корпоративного документообігу. Після створення вони потрапляли в спеціальний розділ системи і розсилалися на пошту всім співробітникам ІТ відділу. Керівник групи ІТ і я могли призначати заявки на будь-якого виконавця або приймати їх до роботи, простий адміністратор міг тільки прийняти заявку. Після виконання роботи виконавець зазначав виконання заявки, присвоюючи їй новий статус, а співробітник, який створив заявку, повинен був відзначити ступінь своєї задоволеності, або згоду зі скасуванням заявки, якщо вона була складена не коректно.
Вид заявок у системі документообігу (у своїй кінцевій інстанції. На описуваний момент вигляд був дещо інший).
Ну все, начебто все ок, процес автоматизований, всі задоволені. Хлопці - ось вам система, вона вам допоможе. Користувачі - ось вам кнопочка - заповнюйте заявки, там всього три поля, і адміни тут же прийдуть на допомогу. Уфф, система налагоджена, працюйте на здоров'я, а я знову пішов займатися процесами в системі документообігу.
Але досвідчений керівник ІТ, який читає цю статтю, здогадається, що не тут-то було. Заявки просто починали копитися в розділі, адміни то «не побачили поштове повідомлення», то «ми не заходимо в систему документообігу», то ще що-небудь веселе. Начебто і заперечити нічого і не винен ніхто. Гаразд, добре ж, став організовувати щотижневу нараду, на якій розбирали кожну не закриту заявку. Часто виявлялося що більшість заявок вже виконано, але не зазначено виконання, тому ми сиділи і нерозумно, як у дитячому садку, тикали в кнопочку «Виконано», а в незакритих писали коментарі про хід виконання. Через пару тижнів картина почала змінюватися іншим чином. Заявки накопичувалися до вівторка, до вечора вівторка більшість закривалася, і в середу до 11 на нараду приходили кришталево чисті адміни, так що і докопатися ні до чого. І тим не менш процес не працював, доводилося саме керувати, а не керувати, і я від безсилля поскрипував зубами.
Мені мнилася ідеальна картина, в якій користувач, якщо у нього перестав шуршати диск або стерся килимок від мишки, писав заявку, яка миттєво відлітала адмінам, вони миттєво розподіляли хто її буде робити, в порядку черги виконували її, а користувач тут же відзначав свою задоволеність. Цей процес представлявся мені як в макдональдсі, коли ти робиш замовлення він відправляється в систему, і співробітники на кухні бачать на моніторі що потрібно приготувати, тут же вільний співробітник готує, а менеджер виносить задоволеному клієнту піднос. Мені хотілося того ж - користувач - заявка - миттєвих підхоплення заявки вільним адміном - виконання - задоволення - оргазм. Насправді ж, крім того, що половина користувачів не писали заявки, а як завжди дзвонили, адміни ще й затягували виконання без особливої причини.
Процесу потрібне було доопрацювання. Адміни повинні були бачити заявки, як тільки вони з'являлися, а крім того, і всі інші заявки, особливо з відповідним терміном виконання. Знову і знову у мене в голові крутилася схема роботи макдональдса, і веселий монітор, з вистрибуючими замовленнями. Власне, а чому б ні?
Деякий час тому я ініціював перехід від утлих табличних звітів в системі документообігу, що нагадують екселівські таблиці, до куди більш приємного, інформативного і відкриває широкі перспективи MS Reporting Services, що входить до складу чесно купленого MS Sql Server. Звіти складаються за допомогою спеціального засобу редагування і розміщення звітів MS Report Builder, який у своєму базисі, напевно, навіть і трохи краще Crystal Reports'a, а вже доброзичливіше - точно! Крім того, переглядати їх можна прямо в браузері і звичайно вивантажувати в будь-який формат.
За допомогою мого колеги, адміністратора баз даних, був написаний звіт в MS Reporting Services, який вибирав з бази заявки, і формував зручний екран, в першу чергу виводячи заявки у яких немає виконавця, в другу які треба виконати сьогодні, потім прострочені, і в порядку убування за датою виконання. Перші пів години нова заявка підсвічувалася жовтим, тож не помітити було не можна. Що б більше не апелювати до совісті адмінів, і навіть не слухати відмовки про «не бачив» - «не чув», був узятий старий ноутбук, на якому запущений браузер зі звітом (звіт оновлювався кожну хвилину), і підключений до одного зі списаних моніторів. А монітор, у свою чергу, повішений на стіну в адмінській, так щоб його було видно з будь-якого кута. Система набула такого вигляду.
Червоним відображалися прострочені заявки. У картці була вичерпна інформація. Заявник, відповідальний, термін виконання, номер заявки. А так само загальна кількість невиконаних, прострочених...
Ну тепер то все? Заявка є, користувач є, адмін є, монітор є. Що ще може піти не так? Адже це повністю реалізована схема макдаківського конвеєра. Всі ланки ланцюга склалися, заявка повинна була котитися по цьому процесу, як дітки в аквапарку по жолобу. Однак же не була врахована прихована від сторонніх очей сторона процесу Мака - мотивація. Адже на кухні у співробітника де факто немає можливості відмовитися від виконання або затягнути час приготування замовлення, але щось же його змушує працювати з максимально можливою швидкістю. А у нас виходили суцільно червоні заявки, які вже пора б або скасувати, або виконати.
Коли дозріло усвідомлення цієї проблеми, почало визрівати і рішення. Моє завдання не карати або милувати працівників, я тільки хочу, щоб все працювало без моєї участі, але в хорошому темпі і без косяків. Чого такого складного в моєму бажанні? Гаразд. Хотіли мотивацію? Ось вам!
Тепер за кожну заявку стали нараховуватися бали. Їх, як водиться, два типи - позитивні і негативні. Позитивні бали (у розмірі 4 штук) нараховуються за виконання заявки. Далі йдуть негативні:-Є. За день прострочення виконання заявки - 1 бал. За кожне додаткове перенесення терміну виконання - 1 бал. У заявці була реалізована функція фідбека від користувача після її виконання, з кількома градаціями якості виконаних робіт. Якщо відгук користувача відрізнявся від «Виконано в повному обсязі і в строк», то приписувалися ще негативні бали залежно від ступеня незадоволеності користувача. Монітор прийняв такий вид (я взяв лютневий звіт, тому дати заявок червоні):
Окремо були виділені заявки, які мають відношення до закупівель, оскільки об'єктивно адміни не відповідають за терміни узгодження і доставки замовленого обладнання.
З'явилася домовленість, що через три місяці після введення даної системи бали за заявки будуть прийматися як об'єктивна якість виконання роботи адміністраторами, і квартальна премія буде нараховуватися відповідно до пропорцій позитивних і негативних балів. 90% позитивних балів - 100% премії. Потім, премія знімається пропорційно збільшенню негативних балів понад 10%.
Бали рахуються завжди за останній квартал, тобто за тими заявками, які були закриті за попередні три місяці, що забезпечує завжди актуальну інформацію, і серйозно мотивує, особливо ближче до премії. Однак же система виходить побудована так, що для отримання премії в повному обсязі працювати треба весь час протягом кварталу, а не тільки під кінець.
В цілому робота цієї системи ефективна. З'явився процес, яким можна керувати, регулювати потоки. Складнощі виникли з привчанням користувачів створювати заявки, але це вирішилося досить швидко, оскільки відразу стало помітно, що адміни набагато швидше реагують на заявки, створені в системі, а не отримані в коридорі. Після написання інструкції для користувачів я дозволили адміністраторам взагалі не виконувати заявки, отримані поза системою, або, якщо у користувача немає можливості створити заявку, створювати їх самим.
Цією статтею я хотів поділитися цікавим досвідом, який можливо десь вже доведений до досконалості. Якщо це так, поділіться своїм досвідом - як змусити людей працювати добровільно, якісно і з повною віддачею.
Чекаю не дочекаюся відгуки людей, яким у своїй суворій життєвій реальності довелося, так би мовити, дізнатися кухню МакДональдс зсередини, тобто попрацювати в системі швидкого харчування. Розкажіть, які методи стимулювання і мотивації можна почерпнути, що б реакція на інциденти в сфері ІТ нагадувала приготування апетитного бутерброда, і користувач від адмінів був задоволений не менше ніж від соковитого бургера.
UPDATE
Для тих, хто писав, що в MD немає ніяких моніторів.
