Управлінський облік для невеликої IT-команди

  

1. Вступна

На ринку IT-послуг працює безліч невеликих незалежних команд (організованих груп розробників, аналітиків, консультантів тощо), які вже не є індивідуальними фрілансерами, оскільки виступають перед своїми клієнтами в якості єдиної команди, але ще (або взагалі) не є повноцінними фірмами, оскільки в них відсутні в закінченому вигляді властиві організаціям «допоміжні» процеси в наступних областях: робота з кадрами, управлінський і фінансовий облік, документообіг і т.п.
 
Не дивлячись на це, невеликим командам також доводиться в тій чи іншій мірі розвивати всі ці процеси, в т.ч. займатися їх «внутрішньої автоматизацією». При цьому дуже важливо знайти розумний компроміс між функціоналом і витратами ресурсів на створення таких «внутрішніх» IT-рішень. Адже нікому не хочеться, наприклад, втрачати години і гроші, вручну проводячи взаєморозрахунки між клієнтами і членами команди. З іншого боку, ніхто не хоче витрачати свій час і гроші на створення або впровадження «наворочених» систем замість того, щоб заробляти гроші на комерційних проектах.
 
Представляючи одну з таких команд, хочу поділитися своїм досвідом створення невеликої системи для управлінського обліку всередині своєї команди у форматі «IT-кейса».
 
 

2. Бізнес-цілі, наявні проблеми та обмеження

Основні цілі:
 
 
     
  1. Забезпечити повну прозорість взаєморозрахунків з клієнтами
  2.  
  3. Забезпечити повну прозорість взаєморозрахунків всередині команди
  4.  
  5. Розуміти в кожен конкретний момент часу хто, які завдання і для кого виконує
  6.  
  7. Забезпечити фіксацію внутрішніх і зовнішніх формальних і неформальних домовленостей щодо термінів та оціночних (максимальних) трудовитрат на виконання завдань
  8.  
  9. Скоротити «непродуктивні» трудовитрати на підготовку звітної документації для клієнтів (рахунки, акти, таймшиту тощо)
  10.  
  11. Мати можливість аналізувати фінансові результати виконуваних робіт
  12.  
Обмеження:
 
 
     
  1. Тимчасові — готовність до використання за 1-2 тижні
  2.  
  3. Фінансові — чим дешевше, тим краще
  4.  
  5. Функціональні — можливість «поступового» нарощування функціоналу одночасно з використанням рішення по мірі поліпшення розуміння поточних і появи нових бізнес-вимог до нього з мінімальними «накладними витратами» на сам процес внесення змін (випуск версій, тестування, Деплой і т.п.)
  6.  
 

3. Ідеї ​​від IT

Виходячи з стоять цілей і наявних обмежень, розглядалися наступні альтернативні варіанти:
 
 
     
  1. Використовувати якесь готове рішення з області «спільного» обліку (наприклад, на базі 1С)
  2.  
  3. Використовувати якесь готове рішення з області автоматизації процесів розробки (наприклад, Redmine)
  4.  
  5. Зробити щось своє
  6.  
Після розгляду «за» і «проти» кожного з цих трьох варіантів було прийнято рішення зупинитися на варіанті «3».
 
Варіант «1» не влаштував тому, що будь-яке таке «готове» рішення довелося б допрацьовувати під специфіку наших завдань, а трудовитрати на доопрацювання з використанням малознайомій платформи навряд чи виявилися б менше створення подібного рішення «з нуля» на базі відпрацьованих технологій. Плюс до цього бентежила необхідність зміни і наших процесів розрахунків під логіку, реалізовану в рішенні.
 
Варіант «2» краще підходив з точки зору відображення специфіки IT-команди, але фінансово-розрахункова частина функціоналу там або була відсутня, або була недостатньо розвинена.
 
Як у випадку «1», так і у випадку «2» бентежила також необхідність оплати вартості ліцензій та наявність «в навантаження» додаткового функціоналу, який в осяжному майбутньому не був потрібний або вже був впроваджений на базі інших систем (наприклад, робота з планами- графіками проектів з функціонала Redmine вже реалізована за допомогою MS Project, а робота з проектними документами і внутрішній портал взаємодії за допомогою Alfresco ECM).
 
У варіанті «3» підкуповувала можливість зробити рівно те, що потрібно зараз і поступово це розвивати в міру розширення і зміни вимог.
 
Що стосується платформи для створення облікової системи «з нуля», то спочатку я планував зробити все в рамках внутрішнього порталу взаємодії на базі Alfresco ECM, проте потім вирішив використовувати MS Access. Access дозволяв зробити все трохи швидше і, що найголовніше, вносити зміни у функціонал в міру необхідності практично одночасно з його використанням. Це дозволяє з низькими накладними витратами відпрацювати інформаційну модель і користувальницької інтерфейс в реальному житті. Потім при необхідності можна перенести вже відпрацьовані технологічні рішення на більш продуктивну платформу. З іншого боку, з урахуванням невеликого розміру команди і, відповідно, невеликих обсягів оброблюваних даних Access цілком підходить для цих цілей.
 
 

4. Концепція рішення

Отже, наше IT-рішення для управлінського обліку в невеликий IT-команді являє собою файл Microsoft Access 2013, що включає в себе базу даних, а також набір форм, запитів і звітів для роботи з нею.
 
Центральної і найбільш складним завданням при розробці подібних рішень є створення інформаційної моделі, що відбиває існуючі бізнес-об'єкти і процеси по роботі з ними. При цьому не існує єдино правильного рішення даної задачі. Однак, недоліки будь-якого запропонованого варіанту, що не видні «неозброєним оком» при проектуванні, дадуть про себе знати, як при розробці, так і при подальшому використанні системи.
 
Кілька спрощена інформаційна модель пропонованого мною варіанту наведена на схемі нижче.
 
 
 
Центральним елементом даної моделі є «Проект». Проекти розрізняються за типами з точки зору спрямованості (внутрішні, зовнішні та пресейли), а також з точки зору способу взаєморозрахунків за них (фіксована оплата за узгоджений обсяг робіт — fixed price, оплата витрачених годин — time & material, без оплати — некомерційні).
 
Кожен Проект пов'язаний з певним Клієнтом, при для одного Клієнта можуть виконуватися кілька Проектів.
 
Модель дозволяє проводити нарахування (білінг) для Клієнтів по Проектам двома способами залежно від типу договору Проекту:
 
 
     
  • На підставі фактично витрачених годин (для T & M проектів) — екземплярів сутності Трудовитрати
  •  
  • На підставі виставлених рахунків, що відображають етапи і умови розрахунків з договору (для FP проектів) — екземплярів сутності Нарахування
  •  
Для деталізації груп робіт в рамках Проекту служить сутність Завдання. Завдання співвідноситься з елементарною або сумарної роботою в ієрархічній структурі робіт (WBS) даного проекту. Таким чином забезпечується стиковка з календарно-мережевим та ресурсним плануванням, виробленим в Microsoft Project. Також Завдання зберігає в собі різні планові оцінки трудовитрат (первісну, узгоджену з Клієнтом і т.п.) і консолідує фактичні трудовитрати з пов'язаних з нею примірників сутностей Трудовитрати.
 
Далі в рамках певної Завдання створюються Призначення конкретним Ресурсам. Ресурс — це людина, член нашої команди. У майбутньому планується також реалізувати підтримку не тільки трудових, але й матеріальних ресурсів. Кожен Ресурс має певну вартість (погодинна ставка).
 
Призначення являє собою домовленість з певним Ресурсом виконати певний обсяг робіт (узгоджена з Ресурсом оцінка трудовитрат) на виконання певних завдань. Наприклад, за Завданням «Створення прототипу» можуть бути створені три Призначення:
 
 
     
  • Підготовка функціональної специфікації — для аналітика Іванова
  •  
  • Розробка прототипу — для програміста Петрова
  •  
  • Тестування — для тестувальника Сидорова
  •  
У процесі виконання Призначення виконавець або керівник проекту щодня фіксує кількість витрачених в цей день годин відповідного Ресурсу допомогою створення екземпляра сутності Трудовитрати.
 
За фактом виконання Призначення керівник проекту оцінює їх якість і фіксує у вигляді оцінки виконання. Ця оцінка згодом використовується при аналізі ефективності Ресурсів.
 
Завершальними елементами бізнес-процесів і запропонованої інформаційної моделі є платежі від Клієнтів і для Ресурсів. Як і в реальному житті, виділяються два види платежів:
 
 
     
  • Вхідний платіж — будь-яке надходження грошових коштів до загального бюджету команди (розрахункові рахунки, готівка), зокрема, надходження за договором від Клієнта
  •  
  • Вихідний платіж — будь витрата коштів із загального бюджету команди, зокрема, оплата робіт Ресурсу
  •  
Платежі не обмежуються розрахунками між Клієнтами та Ресурсами, а відображають абсолютно всі фінансові розрахунки команди (витрати на обладнання, оплата ліцензій, реклама і т.п.). Це дозволяє повністю контролювати фінанси команди, в т.ч. поточні залишки коштів. Також для кожного платежу вказується відповідна видаткова або дохідна стаття, що дозволяє формувати відповідні управлінські звіти про доходи і витрати.
 
Нарешті, за допомогою зіставлення Нарахувань, трудовитрати, вхідний та вихідний платежів автоматично розраховуються поточні баланси по Клієнтам і Ресурсам (хто, кому і скільки винен в результаті).
 
 

5. Завдання з реалізації

Для реалізації концепції, описаної вище, були виконані наступні роботи.
                              
Найменування завдання Трудовитрати, ч-ч
Створення інформаційної моделі, проектування структури бази даних і форм UI 8
Створення таблиць в MS Access, наповнення довідників і введення первинних даних 4
Створення макросів даних в MS Access (реалізація бізнес-логіки на рівні бази даних) 4
Створення форм в MS Access (реалізація інтерфейсній логіки) 8
Створення запитів і звітів в MS Access (реалізація аналітики) 8
Тестування, дослідна експлуатація і доопрацювання 8
Разом: 40 людино-годин .
 
У результаті вийшло таке:
 
 image
 
 

6. Оцінка витрат

Витрати на створення рішення в розрізі статей витрат наведені в таблиці нижче.
    
    
      
      
      
  
Стаття Найменування витрати Кількість Сума Устаткування 0 руб. Ліцензії Додаткових ліцензій крім наявних MS Office не потрібно 0 руб. Роботи Власні трудовитрати по створенню рішення
за ставкою 1.200 руб. за годину
40 ч-ч 48.000 руб.
Разом: 48.000 рублів .
 
 

7. Оцінка вигод

 
7.1. Прямий економічний ефект
           
Найменування Алгоритм розрахунку економічного ефекту Сума
Скорочення трудовитрат на ведення управлінського обліку До впровадження рішення ведення управлінського обліку займало у мене в середньому близько 1 години на день, тобто близько 20 годин на місяць.
Дане рішення дозволило скоротити трудовитрати на ведення управлінського обліку в 2 рази, тобто до 10 годин на місяць.
Економічний ефект в натуральних показниках дорівнює 10 людино-годинах на місяць.
За ставкою 1.200 руб. на годину — це 12.000 руб. на місяць.
12.000 руб. на місяць.
Разом: 12.000 руб. на місяць .
 
 
7.2. Непрямі вигоди
 
     
  1. Підвищення прозорості взаєморозрахунків
  2.  
  3. Зменшення кількості помилок у розрахунках
  4.  
  5. Підвищення якості прийнятих рішень за рахунок появи додаткових аналітичних інструментів
  6.  
  7. Поліпшення взаємин з клієнтами за рахунок чіткої та централізованої фіксації домовленостей про планові терміни і трудовитратах на виконання завдань
  8.  
  9. Поліпшення взаємин всередині команди за рахунок чіткої та централізованої фіксації домовленостей про планові терміни і трудовитратах на виконання призначень
  10.  
 

8. Аналіз ефективності

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

0 коментарів

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