Управління завданнями на розробку. Історія з життя

про те, коли завдань більше, ніж ресурсів на їх виконання, черга завдань з часом збільшується і частина з них можна сміливо назвати «безглуздими».

image
Шалена завдання – коли очікувана користь від реалізації не виправдовує кількості необхідних ресурсів, але Замовник наполягає на необхідності її виконання.
про:
  • управлінні потоком завдань на розробку,
    Як позбавиться від «дурних» завдань?
  • управлінні витратами на розробку,
    Як визначити і вибрати найбільш вигідні завдання?
  • розподілі обмежених ресурсів.
    Як зробити так, щоб усі Клієнти були задоволені, а кількість ресурсів при цьому залишився тим же?

Суть проблеми і її причини
Коротко про компанії, щоб визначити контекст ситуації
За типом діяльності — Регулятор ринку іпотечного кредитування.
Галузь — Фінанси.
Масштаб — Федеральний.
Партнерська мережа від Владивостока до Калінінграда з організацією взаємодії з Партнерами через ІТ-системи компанії.
Напрямок роботи ІТ — розробка та доопрацювання власних корпоративних інформаційних систем, які підтримують бізнес-процесси, як всередині Компанії, так і на стороні Партнерів.
Бюджет на розвиток КІС — 100 млн. рублів на рік.
КІС підтримує бізнес об'ємом 60 млрд. рублів на рік.
Кількість користувачів КІС — > 2000 чоловік.

На момент мого приходу в компанію ситуація виглядала так, що Департамент ІТ давно потонув у потоці завдань на автоматизацію бізнес-процесів і доопрацювання тих, що вже покриті ІТ-рішеннями.
Основна скарга Замовників (внутрішніх Бізнес-Підрозділів) – ДИТ працює неефективно і не робить те, що просять.
Замовники при цьому апелюють до цифр, що за квартал з 40 запитів зроблено всього 5. І так по кожному замовнику: бухгалтерії, фінансовому, юридичному департаменту, департаменту купівлі заставних…

Попрацювавши деякий час я вже сприймав цю ситуацію особисто. Ти намагаєшся зробити щось хороше і зробити це добре для свого Замовника, але в кінцевому підсумку ти все одно поганий для нього.
Це та ситуація, коли бути результативним керівником проектів та «деливерить» недостатньо.
Причини великого потоку завдань:
  1. Обсяг виділеного бюджету на розвиток КІС дозволяє реалізувати багато в ній.
  2. Велика кількість локальних рішень на основі Excel і Access на відмову від яких задано напрям розвитку КІС.
  3. Користувачі і Замовники, які звикли до того, що кожен запит реалізується.
  4. Співробітники ДИТЬ, звиклі до того, що все одно що робити, що попросять то і зроблять.
На малюнку морально-психологічний стан директора ДІТ при вивченні списку запитів з яких він повинен вибрати ті, що ми будемо робити.

image

Крок №1: Введення Техніко-Економічного Обґрунтування для ІТ-запитів
Почали ми з того, що ввели ТЕО для запитуваних розробок / доопрацювань і впровадження ІТ-рішень.

ТЕО складалося з оцінки трудомісткості реалізації завдань та очікуваного економічного ефекту. Трудомісткість реалізації надавав КРЕДИТ, оцінку економічного ефекту — Замовник. Обґрунтування показало які завдання здатні себе окупити і за який період.

Приклад ТЕОСитуація: Компанія регулярно оновлює шаблон Кредитного Договору, який використовується Партнерами при оформленні кредитів.
Проблема: У частині Партнерів співробітники, які оформляють кредитні договори, не мають доступу в інтернет (внутрішня політика банків), з цієї причини існує лаг між виходом нового шаблону договору і отриманням його співробітниками, це призводить до використання застарілих шаблонів і оформлення додаткових угод до укладеними кредитними договорами.
Іноді трапляється, що співробітники Партнерів вносять зміни в шаблон кредитного договору, що призводить до необхідності перевіряти формулювання кредитного договору на відповідність еталонним, і якщо вони не відповідає, проводити аналіз внесених змін і необхідних дій.
Мета: Скоротити час, що витрачається Експертом, на перевірку Кредитного договору за рахунок реалізації перевірки кредитного договору Корпоративної ІС.
Технологічне рішення:
Використовувати ІТ-рішення компанії ABBYY (Сервіс) по розпізнаванню документа і звірку з еталоном.
У КІС необхідно:
  • Реалізувати механізм передачі в Сервіс сканованої копії кредитного договору та відповідного еталона;
  • Реалізувати механізм обробки від Сервісу розпізнаного документа і результатів звірки.
ТЕО
Оцінка трудомісткості реалізації: 1 300 000 рублів.
Очікуваний економічний ефект: Скорочення часу на вичитку кредитного договору (близько 15 сторінок), перевірки відповідності шаблону та наявності змін з 20 хвилин до 5. Середній щомісячний потік кредитних договорів 3 500 штук. Година роботи Експерта варто 523 рубля. Очікувана економія = (15 хвилин * 3 500 КД) / 60 хвилин * 523 рубля = 457 625 рублів на місяць.
Термін окупності: 1 300 000 / 457 625 = 2,8 місяця.
Термін реалізації: 3 місяця з моменту направлення на роботу / на реалізацію.

За пропозицією ДИТЬ, Керівництво Компанії і Бізнес-Підрозділів вирішило, що Компанія не витрачає ресурси/бюджету на завдання, де відсутня економічна вигода. Якщо рішення задачі здатне принести Компанії суттєву не економічну вигоду, то це повинно бути прописано в обґрунтуванні і на цьому загострено увагу Керуючого Комітету, який авторизує дані запити.

Так як в КІС працювали і співробітники Партнерів, ми вважали економічний ефект від реалізації завдань і для них. Для Компанії прямої економічної вигоди, тут могло і не бути, але таким чином ми підвищували привабливість і вигідність співпраці з Компанією. Ми робили доопрацювання на «1 рубль», а економічний ефект від неї отримували всі 200 Партнерів.

Зазначене рішення призвело до того, що звело нанівець величезний потік запитів з дрібними і «дурними» доробками, які не приносили додаткової вартості, але витрачали ресурси.
Період, коли співробітники намагалися автоматизувати все, що могло бути автоматизовано, щоб нічого не робити руками, закінчився.

ТЕО призвело ситуацію до того, що тепер ресурси ДИТ були зосереджені на найбільш вигідних для компанії завданнях і проектах. Воно вирішило першу частину проблеми, тепер ресурси використовувалися ефективно. Залишалася друга — Замовники досі були не задоволені тим, що НЕСЕ не робив те, що просять.

На малюнку зміна в кращу сторону морально-психологічного стану директора ДІТ при виборі запитів на реалізацію.

image

Крок №2: Виділення ІТ-бюджету на кожного Замовника
Кожному Бізнес-Підрозділу встановлювалися на рік показники (KPI), яких воно має досягнути. Для досягнення цих показників Бізнес-Підрозділу породжували запити в ДИТ на надання необхідних ІТ-рішень. Ситуація з ТЕО призвела до того, що завдання заробляють підрозділів отримували більше ресурсів, а обслуговуючі (затрачені) підрозділу опинилися на положенні «бідних родичів.

У перших проекти були спрямовані на те, щоб більше заробляти, а у других на те, щоб заощадити. Економити/підвищувати ефективність власної роботи було менш вигідно, ніж придумувати рішення про те як заробляти більше. Обумовлено це було тим, що ринок іпотечного кредитування зростав.image

Так як ДИТ приймав рішення про те, які завдання реалізовувати і куди направляти бюджет, це породило звинувачення на адресу ДИТЬ, що ми ігноруємо завдання сервісних бізнес-підрозділів і віддаємо перевагу завданням заробляють.

Рішення прийшло не відразу, так як з одного боку все було в порядку. Ресурси потрапляють в самі вигідні для компанії завдання та проекти. З іншого боку, виходить що неправильно ставити перед підрозділами показники, яких вони повинні досягти, і не забезпечувати їх необхідними ресурсами для цього.

Прийняли рішення поділити бюджет між підрозділами згідно з накопиченим обсягом авторизованих завдань. Для цього порахували обсяг необхідних ресурсів на реалізацію всіх завдань і визначили частку завдань кожного бізнес-підрозділи в цьому обсязі. У цих частках «роздали» бюджет.
КРЕДИТ по раніше відповідав за бюджет, але тепер кожен бізнес-підрозділ сама вирішувала на які завдання, на досягнення яких річних показників, направити виділену йому суму.

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

Що отримали
  1. Завдання, які доцільно робити з точки зору вигоди для бізнесу компанії.
  2. Забезпечили реалізацію завдань і проектів кожного підрозділу без необхідності порівнювати важливість завдань підрозділів між собою.
  3. Надали Бізнес-Підрозділу можливість самостійно вирішувати на реалізацію яких ІТ-запитів направити бюджет для досягнення річних планових показників.
  4. Планування витрачання бюджету з Бізнес-підрозділом так, щоб його вистачило на рік і всі найважливіші ініціативи були реалізовані.
  5. Можливість виходити на Бюджетний Комітет з пропозицією щодо збільшення ІТ-бюджету компанії підкріпленим переліком завдань Бізнес-Підрозділів з позитивним ТЕО, які не були реалізовані у минулому році на увазі нестачі бюджету.
На малюнку «Happy End».

image

Післямова
ТЕО Бізнес-Підрозділам було не потрібно, вони в ньому не були зацікавлені.
По-перше — вони хотіли все, що просять.
По-друге — отриманий економічний ефект потім перевірять.
За те ТЕО було зрозуміло і потрібно Керівництву Компанії, тому цей інструмент впроваджувався за рішенням «зверху».
На те, щоб навчити Бізнес-Підрозділу формувати виразне ТЕО пішов не один рік.

Розподіл бюджету між бізнес-підрозділами спричинило проведення організаційних змін всередині ДИТ. Кожен бізнес-підрозділ було закріплено за конкретним Керівником Проектів. Надалі введена позиція Керівника Напрямку. В зоні її відповідальності увійшли управління бюджетом і портфелем проектних і не проектних ІТ-запитів бізнес-підрозділу.

Що почитати по темі
  1. Стратегії формування портфеля замовлень на підприємстві, що випускає продукцію під замовлення
  2. Оптимізація роботи веб-студії. Застосування теорії обмежень у виробництві сайтів
  3. Застосування Теорії Обмежень Систем для постановки процесу
Поділіться в коментарях своїми «кейсами» і посиланнями на відомі вам історії по темі. Цим ви допоможете мені зібрати, а іншим читачам отримати огляд практики.

Якщо після прочитання статті у вас виникло бажання потривожити мою карму Мінусом, то залиште коментар нижче до нього, що в статті і моєї особистості вас зачепило і не сподобалося. Врахую вашу позицію і думку в майбутньому.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.