1. Система в системі Будь-яка компанія є складною системою елементів, пов'язаних між собою потоками...
2. Аналіз бізнес-процесів
3. приклад
4. Методологія
5. приклад
6. Вибір програмного продукту і настройка
7. приклад

Система в системі

Наше деловое партнерство www.banwar.org

Будь-яка компанія є складною системою елементів, пов'язаних між собою потоками різних ресурсів (матеріальних, інформаційних). Само собою, чим краще її керівництво вміє контролювати ці потоки і в потрібний момент впливати на них, коректуючи існуючі та створюючи нові, тим вище ймовірність того, що цілі, які стоять перед компанією, будуть досягнуті. Тобто, фактори часу і якості одержуваної інформації виходять на перший план. У міру зростання компанії її процеси ускладнюються, і вимоги до якості та своєчасності одержуваної інформації зростають. З цієї причини компанія неминуче приходить до необхідності автоматизації своїх процесів.

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

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

Основні кроки

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

1. Отже, перш за все потрібно визначити, для чого нам потрібна автоматизація? Який результат від неї ми хочемо отримати? Тільки відповівши на ці питання, ми зможемо оцінити ефект від впровадження системи і виправданість зроблених вкладень в неї.
2. До запуску проекту важливо також вирішити організаційні питання: визначення термінів, виділення ресурсів на підготовку і проведення проекту, формування проектної команди, планування проекту, а також визначення «на березі» питань стимулювання співробітників, залучених в проект по автоматизації. На організаційних аспектах детально не зупинятимуся, це тема для окремої статті.
3. Аналіз існуючих бізнес-процесів і формування моделі «як треба». Від повноти і правильності проведеного аналізу залежить доля всього проекту, оскільки переробляти в майбутньому вже зроблені настройки буде набагато дорожче, ніж спочатку витратити трохи більше зусиль на те, щоб вибудувати правильну модель. Але ж нами рухає бажання підвищити ефективність наших процесів, чи не так?
4. Зрозумівши, що автоматизується процес, визначаємо правила, за якими він буде працювати, тобто його методологічну складову. Нижче зупинюся на ній докладніше.
5. Сформульовані правила і принципи роботи виливаються в технічні вимоги до майбутньої системи, на основі яких вибирається програмний продукт, в якому буде реалізовуватися система, і формується завдання розробникам.
6. Власне настройка і / або доопрацювання програмного продукту для відображення в ньому всіх особливостей методології автоматизируемого процесу. Те, що найчастіше мають на увазі, кажучи про автоматизацію. Але ми ж бачимо, що це тільки один з необхідних кроків, так?
7. Навчання співробітників роботі в новій системі. Безсумнівно, важливий етап, нехтування яким може істотно ускладнити адаптацію компанії до життя в новій системі. З мого досвіду, часто тільки за рахунок якісного інформування та навчання співробітників істотно полегшується прийняття нововведень співробітниками, які в силу різних причин можуть бути спочатку негативно налаштовані, аж до відвертого саботажу.
8. Дослідна експлуатація. Тут виправляються виявлені помилки і користувачі звикають до роботи в ній. Мені зустрічалися випадки, коли керівництво компанії без розуміння відносилося до етапу дослідної експлуатації, прагнучи скоротити його, неохоче виділяла співробітників для участі в ньому, і т. Д. Таке ставлення, як правило, змінюється, коли в процесі експлуатації виявляються недоробки, які можуть бути викликані як помилками в налаштуванні системи, так і недостатньо коректно сформульованими цілями і завданнями нової системи (згадайте перший питання, на який я звернув увагу в цій статті!).
9. Після завершення дослідної експлуатації і переходу до промислової експлуатації компанія починає працювати в новій системі в повну силу. І тільки тоді з'являється можливість оцінити ефект від проведеної автоматизації: чи досягнуті, і наскільки добре, поставлені цілі.

На окремих важливих кроків я зупинюся нижче більш докладно.

Аналіз бізнес-процесів

Оскільки ми вже згадали автоматизує процеси компанії, необхідно їх виявити, проаналізувати і, в ідеалі, описати. Розуміння взаємозв'язків між окремими діями, спрямованими на досягнення мети компанії (не для цього в ній працюють процеси?) І відповідальних за їх виконання дозволяють коректно сформулювати цілі і завдання кожної операції, проконтролювати її не наробити помилок при проектуванні автоматизованої системи. Виявлення і аналіз «вузьких місць» існуючих процесів (в тому числі нефінансових) дозволяє спроектувати майбутню систему з найменшими витратами. Відсутність розуміння того, що доведеться в подальшому автоматизувати, неважливо в якому програмному продукті, може істотно ускладнити, а в гіршому випадку зробити безглуздим весь проект по автоматизації. Опис існуючих бізнес-процесів і, при необхідності, їх переробка, - окрема велика задача, на якій я не буду тут докладно зупинятися.

Для опису та аналізу бізнес-процесів застосовується різний інструментарій, включаючи BPWin, Visio, Aris і інші. В результаті компанія отримує текстове і графічне опис кожного процесу (див., Наприклад, Малюнок 1), виходячи з якого можна виявити його вузькі місця і внести необхідні корективи в його дизайн.

Малюнок 1. Графічний опис процесу (на прикладі процесу бюджетного планування)
Клацніть мишкою по зображенню, щоб збільшити його

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

приклад

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

Методологія

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

приклад

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

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

Вибір програмного продукту і настройка

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

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

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

приклад

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