"Программирование" договоров

[Алексей Андреев]

Здравствуйте,

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

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

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

Сама работа по "программированию" договора в ПФ сводилась бы к следующему:

1. Установка конфигурации "Программирование договора"
2. Заполнение необходимых реквизитов и статусов и подстройка шаблона под себя
3. Создание задачи на основе шаблонов, в которой отслуживался весь путь жизни договора. Например, при создании отгрузки сразу же создались бы:
- необходимые пункты задач для соответствующих людей с необходимыми чекистами
- необходимые аналитики для подсчета сумм просрочек платежей
- пункты последовательных задач для отслеживания различных этапов по договору и необходимых действий по нему в следствии тех или иных действий


Потому, предлагаю обсудить необходимость внесения следующего функционала на ПФ:

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

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

1. интересна или сама идея "программирования" договоров самим пользователям?
2. и возможно ли ее реализовать в полной мере в ПФ разработчиками?.

Благодарю Вас.

[Dmitry Goncharenko]

Не знаю как пользователям, а мне идея нравится. Более того, как мне кажется, в системе уже есть инструменты для создания такой конфигурации. Было бы здорово, если бы кто-то из интеграторов взялся за эту работу.

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

[Алексей Андреев]

Дмитрий, благодарю Вас за обратную связь.

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

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

Чуть позже данный вопрос "спустится" "c верху вниз" и дойдет до небольших компаний, которые смогут дорасти до формализации процедур и процессов.

Почему я так думаю? Потому что, к сожалению, найти сегодня надежного партнера и контрагента очень непростая задача и поэтому большенство действий будут регламентироваться договорами, а не договоренностями. Не зря за рубежом, как впрочем уже и у нас "присутствует засилие" юристов.

Вот почему, я считаю, что сама по себе идея "программирования" очень полезна и если не сегодня, то обязательно все к ней придем так или иначе в нашем "светлом завтра".

В свою очередь, как я и писал выше, ПФ почти идеальный инструмент, для этого, его необходимо только немного "причесать".

Может и правда, кто-то из интеграторов возьмется за эту задачу? Тем более, крупные компании видя потенциал в этом - согласятся оплачивать подобные доработки. А чуть позже это станет сутью самой системы работы с договорами в ПФ.

[Алексей Андреев]

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

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

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

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

Прекрасно понимаю, что для этого требуется практически полная переработка ПФ и в тоже время, уверен, что в глубинах компании существует группа разработки, которая уже трудится над ПФ следующей версии. Возможно данная идея придется им по душе.

Для чего я все это предлагаю? Сейчас в ПФ не хватает именно визуального отображения логики различных процессов и сценариев. Дракон или любой другой подобный язык визуализации мог бы быть отличным подспорьем в этом направлении, в частности, на первом этапе, он мог бы просто отображать визуальный ряд в виде рисунка и блок схем, где бы ясно читалась логика договора. Разработчик мог бы сначала описать наглядно связи в договоре и затем внедрить ее в жизнь при помощи текущего функционала ПФ. А "завтра" он смог бы уже единожды построив визуальную схему договора сразу описать весь его функционал. В свою очередь, Пользователь ПФ мог бы, опираясь на эту визуальную логику, быстро и без особых усилий освоить основные принципы работы по договору.

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