С.Трухачев, спеціально для Клерк.Ру

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

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

Кожен документ має свій друкований вигляд або декілька друкарських видів. Друковані форми можуть бути регламентовані законодавством або внутрішньою політикою компанії, а можуть мати довільну форму. Наприклад, на основі документа відвантаження повинні формуватися рахунок-фактура, накладна, КС-2 і т.д., які затверджені законом. Форма ж самого акту визначається компанією, який вже має довільну форму, і може мати кілька варіантів. Система повинна дозволяти швидко створювати і настроювати друкарські форми, а також зберігати посилання на зовнішні документи будь-якого типу. Крім того, сам документ повинен зберігати всю інформацію для друкованих форм, так в договорі інформація для друкованої форми договору, відомості робіт, календарного плану, кошторису.

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

Особливістю управління договорами є структурованість та ієрархічність документів. Розглянемо ланцюжок. Не всі ланки можуть бути присутніми в компанії. Спочатку між нашою компанією і замовником укладається партнерська програма на певний період. Програма носить рекомендаційний характер. На основі програми полягають генеральні договору, не містять конкретних позицій. За генеральним договором полягають робочі договору із зазначенням термінів, ТМЦ (робіт), сум і т.д. Також може бути укладено додаток до додаткової угоди. Договір розбивається на етапи зі своїми термінами і сумами, в етапі свої позиції, а по кожній позиції свої витрати. В акті ми можемо в довільній формі закривати етапи і позиції. Аналогічна ланцюжок у відносинах з постачальниками. Тут особливістю є прив'язка позицій субпідрядних договорів до договорів із замовниками. Якщо система автоматизації не підтримує таку архітектуру, то це не управління договорами, а торгово-складський облік договорів.

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

Що ми повинні мати на виході від системи управління договорами? Інформацію про становище компанії, план-факт виконання договорів: доходи і витрати, собівартість, рух грошових коштів.

Планова інформація формується на основі договорів, фактична на основі відвантажень та оплат за договорами.

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

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

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

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

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

Автор працює в Гольдберг-Софт, www.ksss.ru


Стаття отримана: Клерк.Ру

Детальніше »