О Конструкторе документов

Когда общаешься с закупщиками не редко возникает вопрос о проблеме подготовки пакетов закупочной документации (а также ТЗ, проектов договоров и пр. документов). Каждый практикующий закупщик знает, что подготовить качественно (без ошибок и пр.) закупочную документацию и сопроводительные документы достаточно сложно, особенно, если стоит задача сделать это в короткие сроки. Надо также учесть, что у закупщика это не единственная проблема, закупок не одна (и не две, и не пять), а много больше. Также надо учесть и другую работу, так что можно понять какие трудности встают перед секретарем закупочной комиссии. Возникает логичный вопрос -- что делать? С нашей точки зрения в данной ситуации есть несколько выходов. Сейчас все рассматривать не будем, но на одном из них -- генерирование (конструирование) документов остановимся подробнее.

Как генерацию документов понимают в классическом понимании

Есть некий шаблон документа(ов), утвержденный у Заказчика (альбом типовых договоров; стандартный пакет закупочных документов). Эти шаблоны программным образом внесены в некую систему (ЕАИСТ, SAP SRM и пр.). Когда сотрудник заказчика хочет получить конкретный документ, он заполняет некую форму (вэб-клиент или в программе, установленной локально) и на выходе получает пакет документов. Так? Так.

При этом в полученном пакете документов мы можем увидеть кучи пустых мест, которые не заполнены. Например, в типовой документации указано, что у заказчика есть право (т.е. это требование не обязательство и случай взимания может зависеть от каких-то других факторов) брать обеспечение заявки у участника закупки. Если заказчик в данной закупке не хочет брать обеспечение -- он его не берет, но в пакете документов, который будет сгенерирован будет раздел "Обеспечение заявки", а в "Информационной карте" будет пустое (незаполненное) место с требованиями к обеспечению. Возникает резонный вопрос: а зачем мне (участнику закупки) в этой документации указано, что "обеспечение не взимается", но при этом описание, что это такое и куда его надо подавать есть. В качестве примера данного случая можно скачать любую документацию по закупке, которую проводит любой московский заказчик, работающий в системе ЕАИСТ. Зачем???

Все бы ничего и можно смириться, что в документации 100 листов (из которых 80 листов не несут сутьевой информации и их можно было бы смело выкинуть). Но представим если у заказчика возникает необходимость в корректировке (изменении) шаблона документа? Хороший пример -- требование о предоставлении сведений о бенефициарах. В результате тот кто внедрял систему вынужден менять не только шаблон документа, но и отслеживать где новые данные разместить и как соединить обратно все это вместе. Оставим за рамками бесплатно он это делает (в рамках тех. поддержки) или за отдельные деньги.

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

 

Как генерацию документов понимаем мы

Любой документ (шаблон документа) можно разделить на две части:

1. Неизменяемая часть (например, слова "Протокол процедуры вскрытия" и т.п.), т.е. это текст, необходимый для формирования документа (некая описательная часть).
2. Изменяемая (сутьевая) часть -- непосредственно данные, которые необходимы для проведения закупки (Н(М)ЦД; предмет договора; адреса и пр.). На рисунке справа это текст, выделенный зеленым цветом.

При настройке "САП:Закупки" происходит формирование не шаблона документа как конечного и неделимого документа, а настройка блоков информации -- тэгов, которые (могут) применяются в этом документе. В системе Конструкторе документов насчитывается более 750 тэгов. Что это позволяет при эксплуатации "САП:Закупки"? Во-первых, при изменении шаблона документов в части 1 (неизменяемой части) нет необходимости привлекать технического специалиста (сотрудника компании-внедренца). В этом случае (изменить шрифт, исправить текст, добавить оформление) можно самостоятельно. Если же необходимо внести изменения во вторую часть (тэги), то опять же это можно сделать как самостоятельно (благодаря тому, что тэги отделены от кода системы), так и с привлечением специально обученного человека (как сотрудника компании, оказывающей тех. поддрежку, так и сотрудника заказчика, но освоившего инструкцию по использованию Конструктора). Во-вторых, при корректировке шаблонов пользователь может самостоятельно делать личные (персональные) документы (отчеты), которые нужны только этому сотруднику.

Как визуально можно представить работу Конструктора? Представьте себе, что у Вас есть набор строительных материалов (кирпичи; штукатурка; плитка и пр.) -- это блоки информации, которая хранится в системе, тэги Конструктора. Чтобы построить здание нужен проект строительства -- это исходный шаблон документа. Совмещая строительный материал (блоки информации) и проект строительства (шаблон документа) получаем здание -- готовый документ. Как и в жизни при изменении проекта здания мы можем получить из стандартных строительных материалов разные здания, так и в Конструкторе -- применяя блоками информации (тэгам) разные шаблоны документов, можно получить разные документы. Один раз созданный тэг, будет существовать в системе и его можно использовать как для построения документа, так и при анализе выполняемых процессов.

Кроме того, во многих системах есть ограничение на размер вводимой информации в ячейку, например, в ячейка с названием филиала можно вписать только 6 символов, больше -- нельзя ибо ограничение системы. В случае, если название филиала будет больше 6 символов, то конец названия будет отрезан. В Конструкторе документов нет таких ограничений, потому что размер ячейки равен количеству вводимой информации в нее. Да, есть тэги жестко закрепленные, например, относящиеся к разделу "время", но если ячейка (тэг) -- текстовая... ограничением будет служить размер ячейки, который устанавливается правилами базы данных, на котором в данный момент работает Конструктор документов.

Приятный бонус, который получился это то, что Конструктор может выдавать конечный документ в любом из известных форматов данных -- pdf, doc (docx), xls, xml, jpg, tiff, png. Все настраивается по желанию заказчика. Более подробно про Конструктор можно прочитать в инструкции (она приложена к статье).

 

В заключение хотелось бы привести результаты небольшого исследования, которое мы провели у одного из заказчиков, который использует "САП:Закупки" в своей работе. В ходе опроса было получено среднее время, которое секретарь закупочной комиссии тратит на подготовку основных документов в процессе своей работы. Исходные данные опроса были следующими: открытый конкурс; 5 участников; всем участникам были сделаны дополнительные запросы; по результатам рассмотрения заявок трое участников были отклонены. Результат можно увидеть в талице ниже:

Как видно, секретарь закупочной комиссии тратит (в среднем) 13,5 часов на проведение закупки (точнее подготовку документов). Конечно же, это идеальная модель, в реальности человеко/часов на подготовку документов будет больше. Ниже представлена таблица, в которой документы готовятся в системе "САП:Закупки":

В результате получилось чуть более 2 часов, т.е. "САП:Закупки" позволяет достичь экономии во времени немного более, чем в 6 (шесть!!!) раз. При этом данные, внесенные в систему, могут быть использованы (проанализированы) в любой момент.