RECS `2014: особенности применения СЭД/ECM для закупочной деятельности

Автоматизация закупочной деятельности предполагает не просто автоматизацию деятельности с учетом специфики ведения бизнес-процессов, высокую прозрачность и «сквозную» обработку данных, но и в большинстве случаев неукоснительное следование законодательным нормам.

А они таковы, что обязывают организации помимо всего прочего публиковать сведения о закупках в открытом доступе, размещать крупные заказы с обязательным проведением торгов и регулярно отчитываться перед государственными органами о проведенных процедурах размещения заказа. Автоматизация такой работы подразумевает несколько вариантов решений, о которых на форуме Russian Enterprise Content Summit 2014 (RECS) рассказала Дженнифер Трелевич, директор по технической стратегии компании B2B-Сenter.

Внедрение средств управления корпоративным контентом (ECM) и электронным документооборотом (СЭД) — задача непростая для любой организации. А для закупочной деятельности, где процессы сфокусированы на информационной открытости, составлении и предоставлении грамотной отчетности, — это очень сложно. Цепочка взаимосвязанных этапов такой работы предполагает процессы согласования; наличие ПО, реализующего стратегию ERP; систему отчётности; реестр шаблонов; электронную торговую площадку; систему для автоматизации управления работой с поставщиками (SRM); взаимодействие с оператором ЭДО и ведение базы договоров.

«Реализовывать такой проект — это всё равно что передвигаться в темноте. Перед тем как мы взялись за это дело, не было мониторинга. Отчетность велась, но только по отдельным компонентам. Данные вводили вручную, в результате чего случалось много ошибок. Это влекло за собой трудоемкую и затратную по времени сверку данных», — рассказала г-жа Трелевич.

Учитывая объемы и широкий спектр документации, которую необходимо вести и обрабатывать в ходе закупок, и уже используемые в организации системы, ИТ-решение прежде всего должно было отвечать требованиям гибкости, то есть отличаться способностью к интеграции, в том числе для обеспечения «сквозной» отчетности.

«На каждом участке прохождения документов очень важен мониторинг, потому что сроки подготовки и сдачи отчетности очень жесткие, и мы, следуя им, должны понимать, на каком этапе согласования находятся наши документы», — отметила г-жа Трелевич.

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

«Конечно, анализ процессов и сбор данных должны быть на каждом этапе, но всего важнее обратная связь — чтобы понимать, как лучше организовать всю цепочку деятельности», — пояснила она.

Отдельное место в этой последовательности работы занимает согласование документов. Учитывая этот факт, г-жа Трелевич отметила, что в соответствии со спецификой организации согласования в компаниях поставщики предлагают различные варианты решений, некоторые из них представляют собой целостное ПО или системы для согласования, которые обеспечивают легкую интеграцию, например, с электронной почтой и т. д. «Организация и постановка закупочной деятельности включают разные процессы и этапы согласования, и они не всегда связаны друг с другом. Тем не менее мы должны отслеживать ее на каждом этапе — к примеру, на этапе внутреннего согласования. Важно понимать, где находятся документы, заверены ли они или есть необходимость исправить в них какие-то ошибки», — отметила она.

Говоря об использовании шаблоны закупочной документации, договоров и т. д., г-жа Трелевич обратила внимание на характерную для многих организаций интеграцию таких документов с электронным архивом.

«Если вы работаете с электронной торговой площадкой, то, возможно, это будет представлено отдельной системой управления данными о поставщиках SRM. Согласно торговой процедуре мы должны пригласить участников. И какие бы мы записи ни вели, все они должны быть занесены в систему. Также в случае взаимодействия с операторами ЭДО обмениваемся финансовыми документами, в соответствии с 223-ФЗ мы должны иметь всю базу договоров», — сказала она.

Проблема выбора архитектурного решения

Одним из вариантов может быть использование раздельных компонентов решения. К плюсам их использования, по мнению г-жи Трелевич, можно отнести широкий выбор функциональных компонентов, которые не требуют интеграции. «В этом случае мы можем выбрать что угодно, включить это в свое решение, не особо обращая внимание на прикладные интерфейсы (API), сетевой шлюз, веб-сервис. Однако и минусов у такого варианта немало. И первый из них — рутинная работа на стыке компонентов, потому что в таком случае интеграция ведется за счет сотрудников. А это означает большее число ошибок в результате ручного переноса данных, отсутствие межкомпонентной отчётности. Поэтому использование дискретных компонентов больше подходит для малых организаций с небольшим объемом транзакций или тех, кто еще не в курсе возможностей применения других видов решений», — пояснила она.

В случае необходимости получения «сквозной» отчетности при использовании дискретных компонентов придется брать данные из каждой подсистемы, что сложно и затратно по времени. Поэтому другим вариантом может стать монопродуктовое решение. Как рассказала г-жа Трелевич, к его очевидным плюсам можно отнести простую интеграцию систем и подсистем, возможность привлечь интеграторов и консультантов и наличие межкомпонентной отчётности.

Однако у такого варианта есть и минусы: недостаточная «гибкость» в функционале компонентов, их возможное несоответствие российскому законодательству или регламенту организации и работа «в плену» у одного вендора ПО.

«Вероятнее всего, как должно выглядеть на практике такое решение и даже каким должен стать бизнес-процесс, вам продиктует вендор. Есть ли при этом возможность его реструктурирования? Если вы работаете по 223-ФЗ или 44-ФЗ, возможно, это не получится. И заверения вендора в том, что внутренние задачи легко перестраиваются под его продукт, не всегда соответствуют действительности. Кроме того, такие системы стоят очень дорого и становятся не выгодными, если важно иметь возможность убрать из системы один компонент и встроить другой», — отметила г-жа Трелевич.

Третий вариант — мультипродуктовое интеграционное решение, которое обладает высокой гибкостью в выборе компонентов и функционала, способностью формировать межкомпонентную отчётность (при правильной архитектуре) и осуществлять постепенный перенос данных из старых систем.

По словам г-жи Трелевич, этот вариант предполагает сбор воедино разных компонентов, включая те, которые уже успешно работают в организации. «Важно, чтобы можно было интегрировать эти компоненты между собой. У них должно быть нечто связующее — к примеру, общий интерфейс, чтобы была возможность планирования и проектирования архитектуры решений. За счет реализованных принципов интеграции можно получать хорошую отчетность. Этот вариант устроит крупные и средние компании. Но и обяжет правильно проектировать архитектуру решения в начале реализации проекта», — подчеркнула она.

«Самое главное — это планирование и создание архитектуры решения. Но даже во время внедрения все бизнес-процессы должны функционировать. Нельзя остановить работу организации, так же как и единовременно обучить работать по-новому всех сотрудников. Поэтому проект реализуется постепенно, в несколько этапов», — резюмировала г-жа Трелевич.

Тематики: Интеграция, Маркетинг

Ключевые слова: СЭД, ECM, конференция