Некоторые требования к автоматизации управления договорами

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

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

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

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

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

Информация, заложенная в документах, должна работать. И это не только формирование печатных форм. С помощью аналитического учета мы должны получить картину как одного договора, так и портфеля заказов (договоров), т.е. система должна поддерживать OLAP технологии . Система автоматизации должна содержать генератор произвольных отчетов. И поддерживать быстрое добавление новых аналитических справочников (например, для некоторых строительных компаний важен не только объект строительства, но и направление его строительства (коммуникации)). Конечно, наличие специализированных отчетов только приветствуется.

Что мы должны иметь на выходе от системы управления договорами? Информацию о положении компании , план-факт исполнения договоров: доходы и расходы, себестоимость, движение денежных средств. Плановая информация формируется на основе договоров, фактическая на основе отгрузок и оплат по договорам.

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

В последнее время в первые ряды управления договорами компании входят владение нефинансовой информацией о состояние договора. Данное направление называется Управление Задачами ( workflow , проектами). Задача формируется на основе выполняемых работ по договору, находится в определенном состоянии, имеет сроки и состоит в связях с другими задачами. Чтобы пункт договор был выполнен, он должен пройти несколько состояний. Например, разработка программного модуля проходят следующие состояния: технические требования, разработка, отладка, написание документации, опытная эксплуатация. Таким образом, чтобы сдать данный пункт договора, задача должна иметь конечное состояние.

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

Технология внедрения также может отличаться. Некоторые поставщики практикуют комплексную автоматизацию под ключ. Такой подход связан с определенными трудностями. Шансы, что система в целом заработает, намного меньше, чем вероятная работоспособность отдельного модуля. Поэтому некоторые компании предпочитают лоскутную автоматизацию из работающих модулей. Даже если адаптированный программный продукт полностью соответствует техническому заданию – не факт, что он заработает. На этапе проектирования контуры конечного продукта выглядят достаточно зыбко. Возможно, лучше внедрять не под ключ, а использовать метод работающих прототипов. В каждый момент внедрения заказчик уже имеет работающую систему с ограниченной функциональностью. Такой момент позволяет достаточно быстро определить, подходит ли данная система для автоматизации предприятия, а не ждать опытную эксплуатацию. К тому же такой подход позволяет быстро находить и исправлять ошибки.

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

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