НовостиСобытияКонференцииФорумыIT@Work
Документооборот/ECM:

Блог

О необходимости "аналитического задания" для создания Нормативно-Правового Акта

Андрей Колесов
08.02.2015 14:50:37

Еще в январе один из самых активных членов нашего "ECM Клуба" (такой организации формально нет, но она фактически существует в виде нашего ECM-блога и ECM-Фейсбук-группы) Вадим Малых сообщил о намерении создать некоторые нормативный документ, направленный на повышение эффективности системы электронного документооборота Правительства Хабаровского края (сам он – один из ИТ-руководителей этого направления там). Пообещав выложить проект подготовленного документа в свободном доступе для его обсуждения с коллегами-экспертами. Что и сделал на днях в Фейсбуке.

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

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

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

Такая последовательность действий – это хорошо известная (например, их курса "философское понимание научного познания мира") аксиома.

Проблема же заключается в том, что эта аксиома в реальной жизни нарушается сплошь и рядом. В частности, ее несоблюдение стало уже просто общепринятым в нашей российской системе подготовки нормативно-законодательной базы. Я об этом уже не раз писал на примере ряда наших ИТ-законов и подзаконных актов, принятых в прошлом году. Эти документы имеют много недостатков (сложные, запутанные, неоднозначные и пр.), но главный из них: ни у одного из них нет документа, объясняющего – зачем нужны эти законы и нормативные акты, какие проблемы мы хотим решить с их помощью.
Точнее, почти у каждого такое НПА есть некая "пояснительная записка", но по сути это обычно не "записка", а "отписка", которая на сколь-нибудь серьезно обоснование не тянет.

К сожалению, точно такая же ситуация сейчас наблюдается в случае "Положения о СЭД Правительства Харабовского края".

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

Ответов на эти вопросы из Положения я не вижу. Что я сделаю? Скорее всего, или отправлю документ обратно на доработку (чтобы ответили на эти вопросы) или отложу в самых долгий ящик.

Из практики создания наших законов и разного рода НПА мы знаем, что процесс этот небыстрый и часто безрезультативный. Одна из причин медлительности и малой результивности, мне видится, именно в низком качестве подготовительной работы, в том числе на этапе постановки и обоснования задачи. Из научной практики хорошо известно: качественная поставновка задачи – это половина дела. На самом деле, это очень серьезная и трудоемная задача.
Мы пытаемся на ней постоянно сэкономить, а в результате получается "как всегда" – долгий процесс и зачастую не очень качествнный результат (а порой – и просто отсутствие результата).

В общем, повторю базовую аксиому: приступая к решению задачи, нужно сформулировать ее постановку и ожидаемые результаты.

Комментариев: 24

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

09.02.2015 02:07:29

Цитата
Приступая к решению задачи, нужно сформулировать ее постановку и ожидаемые результаты.

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

Еще подробней - по приведенной мной ссылке.

09.02.2015 08:36:40

Нет, это совсем не то. Я написал вам об этом в Фейсбуке.
Скажу еще.
Перед тем, как строить самолет или сложное здание, создается проект. Сначала пишется ТЗ, потом - проектная документация. А уже потом приступают к строительству.
А мы сначала строим, а потом под это делаем обоснование. И документацию.

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

Почему у нас уже лет 10 говорят о переходе на электронные документы, пытаются что-то сделать. А дело идет черепашьими шагами? Да, потому, что мы пытаемся создать здание, без создания проекта.
Создаем фундамент, как умеем, потом начинаем возводить стены. На уровне третьего этажа выясняется, что фундамент не подходит....Переделываем. На уровне пятого этажа опять понимаем, что сделали не так...

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

Начать нужно, в том числе, с описание понятийной базы и общей логики работы системы. Смотрите, проблемы видны уже в написанном вам комментарии. Вы вводите понятие "официальный документ". А что это такое? Чем "официальный" отличатся от "неофициального"? И чем "документ" отличается от "информации". Вы путаетесь заменить понятие "документ" понятием "информации", что является ошибкой. И можно почти гарантировать, что эта идея у вас не пройдет утверждения. Не из-за косности оппонентов, а потому что они будут правы.

Идея использования простой ЭП подписи понятна, но как и для чего вы собираетесь реализовывать ее из Положения не понятно.

У вас в Положении просматривается мысль, что "электронный документ" = файл. Это представляется принципиально неверным. Как вы представляете себе применение простой ЭП к отдельному файлу?

По традиции нашего документоведения у вас центральным компонентом СЭД является документ. Документоведов не интересует процесс создания документа, их интересует только результат. А СЭД - это процессы!!! Имено процессы, документы - средство поддержки процессов, а не наоборот.

Т.е. нужно говорить не о юридической значимости документов, а о юридической значимости процессов.

Тогда так и нужно написать
"Все действия пользователей в СЭД (после входа в систему с помощью авторизации) являются юридически значимыми. В том числе юридически значимыми являются все документы, создаваемые пользовалем в СЭД, и все сообщения, передаваемые через СЭД".

А далее нужно четко прописать: как вы будет обеспечивать и доказывать (в том числе в суде) эту юридическую значимость.

Например
"Юридическая значимость действий и документов пользователей обеспечивается с помощью независимой системы протоколирования, реализованной в СЭД, надежность и безопасность которой обеспечивает оператор. Юридическая значимость доказывается с помощью предъявления протоколов (технологических документов создаваемых СЭД), проведения аудита системы независиым экспертами и пр...."

Но у нас часто документы создают вне СЭД. Вы делаете файл в Word, а уже потом вводите в СЭД. Нужно описать процедуру такого ввода, потому что именно в это момент документ получает ЭП (простую). Т.е. файл, который хранится на флешке пользователя, ЭП не имеет, а введенный в СЭД - имеет. Это нужно четко объяснить и показать, как вы потом докажете, что введенный в СЭД документ имеет подпись конкретного человека.

То же самое с копированием....

Ну. и так далее...

09.02.2015 08:47:54

Про юридическую значимость можно подумать. Можно переделать этот раздел - Юридическая значимость документов и процессов в СЭД и добавить ваши формулировки. Впринципе мне мысль нравится.
Про остальное попозже отвечу.

09.02.2015 08:54:13

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

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

09.02.2015 09:07:02

ТЗ на проект документа, это что-то выходящее за рамки моего понимания. Проект это и есть такое ТЗ, пока он не стал документом. В чем проблема его перекраивать и переделывать? Никаких проблем. Главное делать это до того, как проект станет документом.

Написано много лишнего, а многие важные вещи не затронуты - вот такой конкретики и хотелось бы от экспертов услышать. Что не раскрыто, что лишнее.

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

09.02.2015 09:32:46

Что такое ТЗ на документ?

Все очень просто. Посмотрите на классическую схему любой исследовательской работы. Например, на кандидатскую диссертацию

1. Сначала формулируется тема - название работы
2. Определяются проблемы, которые нужно решить в рамках этой работы.
3. Формулируются задачи, с помощью которых можно решить эти проблемы.
4. Собственно, решаются эти задачи.
5. Формулируются выводы и рекомендации, по результатами работы.

Ваше положение - это 5-й пункт. Вам нужно сначала сделать первые четыре.

09.02.2015 09:37:01

Обязательно воспользуюсь, когда буду писать диссертацию smile:) А сейчас мне надо написать НПА. Причем, по двум причинам (ГИС и простая ЭП) мне просто придется его писать. Поэтому хочется им закрыть еще какие-то вопросы. Теоретически конечно можно было выпустить НПА из двух пунктов:
1. СЭД это ГИС.
2. Ключом простой подписи является логин/пароль. Его нельзя разглашать.

Все!

09.02.2015 09:49:45

А это относится не к диссертации, а к АБСОЛЮТНО любой работе. К ЛЮБОЙ. Прежде чем, что-то делать, нужно ответить на вопрос "зачем".

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

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

09.02.2015 09:34:06

Я вам написал в Фейбуке. Вам нужно написать ТЗ-пояснение, которое будет читать губернатор. Не сосед по кухне, а губернатор.

09.02.2015 09:38:27

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

09.02.2015 09:44:13

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

09.02.2015 09:48:21

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

09.02.2015 10:09:06

"Документ о документ" (ТЗ) нужен вначале, а не в конце. Он нужен, в том числе и для согласования. Чтобы люди находили в нем ответы на вопросы, которые я вам задаю по ходу чтения Положения.
А в нем (в положении) - много непонятных и противоречивых моментов.

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

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

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

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

09.02.2015 10:14:32

Цели я и так знаю (и описывал их много раз). Уход от тупого обмена документами (даже и электронными) там где достаточно автоматизированного процесса. Надо расписать почему это выгодно? По-моему и так очевидно. Отсюда простая ЭП и юр. значимость.

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

Собственно это основное. Я плохо представляю как на основе этого (и главное зачем) писать целое развернутое ТЗ.

09.02.2015 10:18:52

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

09.02.2015 10:22:49

Особенно если цели не разделяют настолько, что тут лучше не прояснять какие-то вещи, а по возможности скрывать smile:)

09.02.2015 08:52:28

Что неправильного в том, что любая информация, попавшая в систему, это документ?

09.02.2015 09:26:11

Не любая, а лишь та, которая зафиксирована в системе в виде документа.

Вам нужно оперировать понятием документ, не вводит лишние понятия.
Вы вместо "документ" используете "информация, зафиксированная с системе". Но это и есть документ. Вместо одного слова – три. Вы запутываете пользователей и весь текст.

Тогда и напишите

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

Это определение годится и для бумаги (средства – бумага, ручка) и для электроники.

Но вы говорите о конкретной СЭД.
Значит нужно еще отдельно уточнить:

"Документы СЭД Правительства – это документы, которые управляются средствами, предоставляемыми Оператором СЭД" (это не только ИТ, но и бумага, ручки).

А дальше нужно ввести категории документов

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

Внешние – это как бумажные (известные средства – бумага, ручка, грамотность, зрение). Например, файлы DPF, DOC – (общедоступные средства, хорошо бы их сертифицировать, признать).

Внутренние – работа только через СЭД.

Обратите внимание, СЭД работает и с внешними документами, но она работает не с содержанием документов, а только на уровне карточки (это уже внутренний документ)

Но есть и сугубо внутренние документы (сообщения, пересылаемые внутри СЭД, например).

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

Кто выполняется преобразование документов? Это делает СЭД, под управление Оператора.
Кто должен подтверждать юридическую значимость такого преобразования? Оператор!

Вот, собственно, я тут вчерне и описал логику работы СЭД и Положения
Все очень коротенько получилось smile:)

09.02.2015 09:39:25

Что значит зафиксирована в виде документа? Вы рекорд имеет в виду? Это у нас обзывается тут "официальный документ" smile:)

09.02.2015 09:52:46

Вы опять все пытаетесь свести к непонятному термину "официальный документ". Вы постоянно предсталяете документ только в виде бумаги.

Посмотрите на предложенное мной определение.

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

"Документы СЭД Правительства – это документы, которые управляются средствами, предоставляемыми Оператором СЭД" .

Все, больше ничего не нужно.

09.02.2015 10:04:57

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

09.02.2015 10:16:17

MoReg - это рекомендации по АРХИВНОМУ хранению документов

А мы ведем речь о СЭД! Об автоматизации деловых процессов! В них используются совсем не только АРХИВНЫЕ документы.

Вот потому мы и топчемся с электронными документами, поскольку все время живем представлениями Архивистов 19-го века.

09.02.2015 10:45:36

Не совсем так. Не по архивному хранению, а по системам управления записями. Это не совсем одно и то же и эти рекомендации активно применяются при разработке в том числе ЕСМ систем, т.к. им очень плотно надо взаимодействовать (или содержать в себе) с этими самыми системами управления записями.
По архивному хранению это OAIS и иже с ними.

Но это уже совсем другая история smile:)

09.02.2015 10:53:53

По факту - это одно и то же.

Я уже сказал по теме почти все, что можно сказать.
Могут только предложить вам отслеживать график реализации вашего проекта и проанализировать эффективность выбранного вами варианта.

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

Я уверен, что при правильной организации эти трудозатраты (в том числе по времени) можно сократить в разы. И с получением результата максимально приближенного к задуманному.

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии