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

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

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

Представляючи одну з таких команд хочу поділитися своїм досвідом створення невеликої системи для управлінського обліку всередині своєї команди у форматі «IT-кейсу».

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

1. Забезпечити повну прозорість взаєморозрахунків із клієнтами
2. Забезпечити повну прозорість взаєморозрахунків усередині команди
3. Розуміти у кожен конкретний момент часу хто, які завдання та для кого виконує
4. Забезпечити фіксацію внутрішніх та зовнішніх формальних та неформальних домовленостей щодо термінів та оціночних (максимальних) трудовитрат на виконання завдань
5. Скоротити «непродуктивні» трудовитратипідготовку звітної документації для клієнтів (рахунки, акти, таймшити тощо)
6. Мати можливість аналізувати фінансові результати виконуваних робіт

Обмеження:

1. Тимчасові – готовність до використання за 1-2 тижні
2. Фінансові – що дешевше, то краще
3. Функціональні – можливість «поступового» нарощування функціоналу одночасно з використанням рішення у міру покращення розуміння поточних та появи нових бізнес-вимог до нього з мінімальними «накладними витратами» на сам процес внесення змін (випуск версій, тестування, деплой тощо)

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

Виходячи з цілей і наявних обмежень, розглядалися такі альтернативні варіанти:

1. Використовувати якесь готове рішення в галузі «загального» обліку (наприклад, на базі 1С)
2. Використовувати якесь готове рішення в галузі автоматизації процесів розробки (наприклад, Redmine)
3. Зробити щось своє

Після розгляду «за» та «проти» кожного з цих трьох варіантів було прийнято рішення зупинитися на варіанті «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 людино-годин.

В результаті вийшло таке:

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

Витрати створення рішення у межах статей витрат наведені у таблиці нижче.

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

Разом: 48.000 рублів.

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

7.1. Прямий економічний ефект

Найменування	Алгоритм розрахунку економічного ефекту	Сума
Скорочення трудовитрат на ведення управлінського обліку	До застосування рішення ведення управлінського обліку займало в середньому близько 1 години щодня, тобто. близько 20 години на місяць. Це рішення дозволило скоротити трудовитрати ведення управлінського обліку вдвічі, тобто. до 10 години на місяць. Економічний ефект у натуральних показниках дорівнює 10 людино-годин умісяць. За ставкою 1.200 руб. на годину - це 12000 руб. в місяць.	12.000 руб. в місяць.

Разом: 12.000 руб. на місяць.

7.2. Непрямі вигоди

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

Наведені вище розрахунки свідчать про термін окупності даного рішення менше 4-х місяців навіть при розгляді тільки прямого економічного ефекту.

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

Тобто. можна з упевненістю стверджувати про високу економічну ефективність цього рішення.

Хардкорна конфа за С++. Ми запрошуємо лише профі.

---