Наверх

Продумка 5. «Просьбы» как замена «Служебных записок»

Архив
Время чтения: 3 минуты
32
Продумка 5. «Просьбы» как замена «Служебных записок»

Продумка 5. «Просьбы» как замена «Служебных записок»

Коммуникации подразделений, горизонтальные связи… как много на эту тему написано. При этом единственной возможностью официально обратиться сотруднику одного подразделения к другому является использование «Служебной записки». Но «служебка» это достаточно неповоротливый инструмент и плохо подходит для оперативного решения рабочих вопросов.  В итоге СЭД/ECM используется только для официального документооборота, и она остается в стороне от реальной работы сотрудников. Горизонтальные коммуникации чаще всего реализуют с использованием электронной почты, однако она тоже имеет свои недостатки - низкая официальность, а так же отсутствие возможности собирать статистику.

Я предлагаю использовать такой инструмент как «Просьба». «Просьба» - это документированное обращение одного сотрудника организации к другому вне зависимости от иерархии подчинения, она носит официальный характер, однако не обязательна к исполнению. Сотрудник, к которому адресована «Просьба», обязан как-то на нее отреагировать – принять в работу или отказаться от нее. Принятая в работу просьба становится уже обязательной к исполнению. В большинстве современных СЭД/ECM работу с «Просьбами» настроить несложно, так же процесс работы с ними нужно добавить в корпоративные регламенты (стандарты).

Рисунок 1. Подготовка "Просьбы"

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

Рисунок 2. Путь прохождения "Служебной записки" и "Просьбы"

«Просьбы» полностью не заменят и не исключат «Служебные записки», там где нужна максимальная официальность, например, при необходимости выделения материальных средств без «Служебной записки» не обойтись. По моей практике функционал «Просьб» оказывается достаточно востребованным, он дает новый толчок использования СЭД/ECM, а их количество в системе обычно существенно превышает количество «Служебных записок».

Оригинал статьи расположен по адресу: http://www.idoc.ru/index.php/produmki

 

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 32

Александр, вы описали какую-то надуманную проблему. Возможно, в какой-то конкретной СЭД она вполне реальна, но без ее указания материал смотрится крайне непонятно.

Андрей, признаюсь честно эта тема редкий случай когда идея была не моя. Это было предложением одного из моих заказчиков. Я поначалу воспринял ее так же как и Вы - в штыки. Но давайте попробуем оторваться от догм нашего российского делопроизводства и приблизиться к реалиям бизнеса. Нужно что-то среднее между служебкой и просто письмом по почте. Нужно что-то достаточно официальное при горизонтальных коммуникациях, но при этом не такое забюрократизированное как служебка. Поверьте, я эту тему не в одной компании запустил, везде люди связанные с делопроизводством воспринимают ее в начале без восторгов, однако реальные пользователи очень часто ее используют. Например, у одного из моих заказчиков создается порядка 200-300 поручений в день, а просьб создается порядка 100-150, служебок менее 100!!!

Возможно, в какой-то конкретной СЭД она вполне реальна, но без ее указания материал смотрится крайне непонятно.

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

А что просто мешает оптимизировать маршрут прохождения служебных записок? То, что я прочитала, это все служебные записки. Просто одна служебная записка с согласованием, а другая без согласования. Вот и всё.

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

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

А что просто мешает оптимизировать маршрут прохождения служебных записок? То, что я прочитала, это все служебные записки. Просто одна служебная записка с согласованием, а другая без согласования. Вот и всё

 Елена, не совсем так. Методологически Просьба и Служебка сильно различаются.

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

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

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

 Я так решил потому что нигде не встречал никакого упоминания про подобный функционал. Например, я внедряю решения на Docsvision, уверяю Вас, что функционал Просьб никем кроме меня не реализован. Елена Дмитриева внедряет Directum, судя по ее комментариям для нее этот функционал тоже вновь. Ну вот я Вам привел двух лидеров рынка у которых этого функционала "из коробки" нет.

Поэтому думаю Вам лучше привести пример систем у которых этот функционал реализован.

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

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

Что  касается реализации функционала в системе, то в системе DIRECTUM используется понятие "Задание". Оно тоже со сроком и указанными вами преимуществами для оперативной работы.

Александр, специально подняла информацию по служебным запискам. Служебная записка пишется не только от руководителя к руководителю, но и от специалиста к специалисту

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

Никто не запрещает устанавливать сроки в служебной записке и давать обратную реакцию.

 Это можно сделать только в тексте, отдельного поля нет, соответственно отчет о просрочке выполнения Служебки нельзя сформировать.

Что касается реализации функционала в системе, то в системе DIRECTUM используется понятие "Задание".

 Задание это другая тема. Задание (я правда больше люблю термин "Поручение") выдается строго по иерархии вниз и обязательно к исполнению. Просьбу же можно писать не соблюдая иерархию и получатель может отказаться ее выполнять.

Задание это другая тема. Задание (я правда больше люблю термин "Поручение") выдается строго по иерархии вниз и обязательно к исполнению.

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

Нет. Вы путаете официальную терминологию делопроизводства и терминологию конкретной системы. Задание в DIRECTUM - это не поручение. Его может отправить любой пользователь системы любому, никаких ограничений нет

Есть техническая возможность системы, а есть методологическая (регламентная) возможность для людей и они могут сильно отличаться. В своей Продумке 1 я раскрыл тему ограничения по отправке поручений (заданий). Описывая Просьбы я скорей писал о методологии, о новом виде документа, который закрыл бы пустую брешь, а не о том как это можно было бы технически реализовать.

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

 В других системах они точно есть.

Есть техническая возможность системы, а есть методологическая (регламентная) возможность для людей и они могут сильно отличаться.

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

В других системах они точно есть.

Ну вот видите. Тогда зачем придумывать что-то новое, а не использовать базовый функционал системы? Потому что регламент превыше эффективности? Не знаю, не знаю... Зато знаю, что есть успешные случаи отработки возражений "А почему у вас в системе рядовой сотрудник может отправить задание топ-менеджеру?" ;-)

Андрей, технически можно использовать один инструмент "Задание", но различными настройками для пользователей его все равно нужно превратить в два вида документов: "Поручение" и "Просьба".

Причины следующие:

1.  Ни один руководитель не поймет если ему от подчиненного или сотрудника другого подразделения придет "Поручение" или "Задание", задание ему могут давать только его руководители. А вот "Просьба" будет воспринята нормально.

2. Жизненный цикл и процесс у "Поручения" и "Просьбы" существенно отличается.

3. Для "Поручений" и "Просьб" нужно строить отдельные отчеты, т.е. их все равно нужно как-то технически разделять чтобы, например, программист смог построить индивидуальный отчет.

4. Ну и конечно набор полей у них различен, например, у "Просьбы" не нужно поле "Соисполнители", которое есть у "Поручения".

5. Реакция получателя на "Просьбы" и "Поручения" разная. "Поручения" я буду рассматривать в приоритетном порядке, соответственно для меня они должны быть отделены в системе от "Просьб".

Ни один руководитель не поймет если ему от подчиненного или сотрудника другого подразделения придет "Поручение" или "Задание"

Это просто неправда. Для опровержения постулата "ни один" достаточно всего одного контрпримера. Даже у меня (хоть я и не внедренец) контрпимеров больше одного.

Жизненный цикл и процесс у "Поручения" и "Просьбы" существенно отличается

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

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

А предложенные вами возможности все равно не дадут построить мощную систему отчетов. Точнее не дадут построить ее значительно эффективнее, чем без них.

Ну и конечно набор полей у них различен, например, у "Просьбы" не нужно поле "Соисполнители", которое есть у "Поручения".

В DIRECTUM нет поля соисполнители у задания.

Александр, зачем вы упорно доказываете мне, что другие схемы плохи, приводя иллюстрацию только своими схемами, а не теми самыми другими?

Александр, зачем вы упорно доказываете мне, что другие схемы плохи, приводя иллюстрацию только своими схемами, а не теми самыми другими?

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

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

А зачем останавливаться на просьбах? Здесь же поле непаханое для различных реализаций: подчинённому - Задание, Поручение или Наказ; равному по званию - Просьбу или Прошение; вышестоящему - Челобитную... Напоминает историю о внедрении в одном из "филиалов" РПЦ, где кнопку "Старт" хотели назвать "С Богом!", а "Принять" - "Аминь".

А если серьёзно - согласна с коллегами, проблема более чем надумана. Схожий функционал есть в бОльшей части существующих СЭД/ECM. А руководителей, комплексующих по поводу того, что подчинённый может направить им задание, становится всё меньше.

Валентина, спасибо что разбавили наше обсуждению юмором :)

А предложенные вами возможности все равно не дадут построить мощную систему отчетов. Точнее не дадут построить ее значительно эффективнее, чем без них.

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

В DIRECTUM нет поля соисполнители у задания.

 Странно. А как же, например, Генеральному директору дать поручения одному своему заму и привлечь в помощь к исполнению других замов?

Замечательное изобретение "Просьба" лишь для тех компаний, которые заинтересованы в эффективности самой работы, а не в процессе перекладывании бумаг (пусть даже электронным путем). Остальные успешно используют Служебные записки, вооружаются регламентами, тычат друг другу в нос прописанными в них сроками рассмотрения (минимум 3 рабочих дня). Эх, где бы не работать, лишь бы не работать!!! )))

А как же, например, Генеральному директору дать поручения одному своему заму и привлечь в помощь к исполнению других замов?

Есть многофункциональное поле "Маршрут". Там можно указать одного или нескольких исполнителей. Или вообще бизнес-процесс (так называемый типовой маршрут). Тогда исполнители будут подбираться системой.

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

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

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

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

Это обсуждение не возникло бы, если бы мы работали все с одной системой)

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

Странно. А как же, например, Генеральному директору дать поручения одному своему заму и привлечь в помощь к исполнению других замов?

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

Весь возникший спор лишь только  из-за терминологии и особенностей систем.

"Просьба" тоже имеет место быть в системе , где нет механзма свободной маршрутизации(опять же тем, кто не работает в Directum может быть не понятно).

Это обсуждение не возникло бы, если бы мы работали все с одной системой

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

Просьба" тоже имеет место быть в системе , где нет механзма свободной маршрутизации(опять же тем, кто не работает в Directum может быть не понятно).

 Улыбнуло. Не обижайтесь, но тема свободной маршрутизации почти у всех вендоров решена уже лет 10 назад.

И действительно Просьба,тогда решит вопрос с излишком Служебок.

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

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

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

Я мог бы признать все это если бы мне аргументировали - в чем же Просьба не решает указанные мной проблемы?

Решает, конечно, но дело не в этом.

Здесь можно провести аналогию с анекдотом советских времен. "Просьба" - это шариковая ручка, специально сконструированная американцами для того, чтобы писать в невесомости. Решает ли она свою задачу? Да, безусловно. Делает это хорошо? Опять же, да. Еще и выглядит модно. Вот только у русских в это время есть обычные графитовые карандаши. И они пишут в невесомости, ничего не изобретая.

Решает, конечно

 Значит я не зря писал эту Продумку.

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

 Улыбнуло. Не обижайтесь, но тема свободной маршрутизации почти у всех вендоров решена уже лет 10 назад.

Правильная оговорка, ПОЧТИ, но не у всех, не будем показывать пальцами- это не прилично)))))

действительно, есть такие организации, где без регламента нельзя и в кабинет к рук-лю войти

 Я уже не помню когда с такими не работал.

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

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

Кстати, покажите все-таки пальцем, почему же неприлично - если нет какой-то функциональности у какого-то продукта, то почему бы об этом не заявить? Только не попадите впросак :) ))))

Я уже не помню когда с такими не работал.

O_o

Как у вас все сурово. Я, помнится, еще в конце 90-х будучи студентом даже к главному технологу завода ходил, не особо соблюдая какие-то регламенты, а с непосредственными начальниками так вообще свободно общался. Про более поздние места работы можно и не говорить - еще все проще.

Андрей, я описАлся. Жаль, что Вы за это зацепились и едко прокомментировали, описка по моему достаточно очевидна. В моем предыдущем посте фраза должна быть без частицы "не" и звучать так: "уже не помню когда с такими не работал".

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

Чтобы прокомментировать, или зарегистрируйтесь