Обсуждение кейсов. Кейс №1 «Цифровизация межотраслевой нормативно-правовой деятельности»

Просмотров: 3178
Автор:
Редакция Global CIO

Начинаем обсуждение кейсов «Интеллектуального Марафона 2017». Представляем первый кейс от Анатолия Белайчука, Chief Evangelist компании Comindware, «Цифровизация межотраслевой нормативно-правовой деятельности» и решения участников нашей игры. Ждем ваших комментариев, замечаний, альтернативных вариантов решений.

Описание задачи:

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

Ответы участников «Интеллектуального Марафона 2017»

Решение Виталия Шишаева, ОАО «ГСК «Югория»:

Концептуально решение состоит из двух основных пунктов:
1. Формализовать и утвердить схему и регламент процесса принятия проекта закона, учитывающих необходимость оценки его ожидаемого эффекта и оценки полученного фактического эффекта с целью корректировки.
2. Выбор и внедрение инструмента для организации единого пространства для обсуждения.
Этап 1. Формализация и утверждение процесса
1. Определение этапов процесса, в частности, обязательным должен быть этап подачи инициативы и этап оценки последствий принятия закона.
2. Определение политик перехода с одного этапа на другой. Например, для перехода законопроекта с этапа «Инициатива» на этап «Разработка прототипа» должны быть подготовлены и согласованы следующие документы:

  • Описание необходимости законопроекта
  • Описание ожидаемого эффекта с обоснованием.

3. Определение процессных ролей и ответственности.
4. Определение процедур, методик для каждого этапа процесса. Например, методика оценки экономического эффекта для стадии «Инициатива».
5. Определение KPI процесса.
6. Формирование и утверждение регламента процесса.
Этап 2. Выбор и внедрение инструмента коллективной работы.
1. Подготовка требований к инструменту (системе) коллективной работы над документами
В частности, должны быть учтены и проработаны следующие требования:
Система должна позволять работать в ней сотрудникам различных ведомств в безопасном режиме
Система должна поддерживать возможность коллективной работы над документом с применением механизмов логирования изменений и сохранения версий документов
Система должна поддерживать возможность привязывать бизнес-процесс к документу
Система должна позволять организовывать справочники с произвольным набором произвольных атрибутов
Система должна поддерживать контекстный поиск по документам
Должна быть предусмотрена возможность интеграции с правовыми системами
Должна быть предусмотрена возможность интеграции с социальными сетями
2. Согласование требований со всеми ведомствами.
3. Выбор и закупка решения.
4. Реализация процесса согласования документов, утвержденного на Этапе 1.
5. Реализация интеграций с правовыми системами.
Этап 3. Внедрение процесса и системы в опытную эксплуатацию.
Этап 4. Анализ результатов и корректировка процесса/доработка системы, перевод в промышленную эксплуатацию.
Этап 5. Непрерывное совершенствование процесса.
В качестве технологии автоматизации предлагается использовать «1С-Битрикс: корпоративный портал», который:
1. Удовлетворяет большинству требований по работе с документами, процессами.
2. Дополнительно обладает функциональностью социальных сетей и работе в группах, что позволит улучшить коммуникации и не вызовет отторжения (к социальным сетям уже все привыкли).
3. Имеет открытый исходный код и большое количество разработчиков на рынке, что позволит интегрировать систему с различными сервисами и не зависеть от одного поставщика.
4. Является отечественной разработкой.

Решение Валерия Лиховских, «Нижегородский ИВЦ», структурное подразделение ГВЦ, филиала ОАО «РЖД»:

На сегодняшний день вряд ли найдется готовая система, пригодная для создания такого межведомственного электронного взаимодействия.
Работа над документами в формах MS Office не удобна  по причине невозможности одновременной работы над документом нескольких сотрудников и вероятности случайной потери их результатов работы (затирание версии документа одного сотрудника версией документа другого, например, при использовании MS SharePoint).
Существующие системы контроля версий в основном ориентированы на контроль версий исходных кодов программ. В принципе, они могут быть использованы для групповой работы первого уровня в ведомстве при выработке правил и соглашений оформления текста. Системы контроля версий не интегрированы с ведомственными системами документооборота (СДО).
 Из перечисленного формулируются следующие требования.
1. Система должна поддерживать двухуровневую групповую работу над текстами документов. Первый уровень — групповая работа сотрудников какого-либо ведомства. Второй уровень — групповая межведомственная работа сотрудников.
2. Групп первого уровня, работающих над одним документом, может быть множество, в каждом ведомстве своя группа.
3. Не все рабочие моменты подготовки и обсуждения документов групп первого уровня одного ведомства могут быть видны (делегированы)  группе второго уровня.
4. Рабочие моменты подготовки и обсуждения документов групп первого уровня одного ведомства могут быть видны (делегированы)  группе первого уровня другого (других) ведомства только через группу второго уровня.
5. Система должна быть интегрирована с внутренней СДО ведомства, т.е. иметь возможность экспортировать подготовленные в системе тексты и/или импортировать для дальнейшей работы внутри ведомства тексты документов в/из СДО.
6. Система должна автоматически строить ссылки на другие документы во внешних системах ведомства или публичных системах (в интернет), если в разрабатываемом документе встречается ссылка на другой документ. В каждом ведомстве эти ссылки могут быть свои.

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

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

Решение Юрия Мичурина, ООО «ОМК-Информационные технологии»:

1. Организовать работу в единой системе документооборота между всеми ведомствами

2. Систематизировать, упорядочить информацию, поступающую из каждого ведомства, здесь целесообразно использование технологии Big Data.

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

Решение Николая Матвеева, ОАО «Торговый дом «Холдинг-Центр»:

Здесь, на мой взгляд, речь должна идти не об административном регламенте, а о философии. И вовсе не факт, что замкнутая цифровая структура вообще необходима. 
В описании кейса все очень напоминает мечты академика Глушкова образца года этак 1965-70 про ОГАС – общегосударственную автоматизированную систему.
Конкретнее: чем плоха электронная почта при обсуждении законопроекта? Что мешает там вести «содержательное постатейное обсуждение»? Обсуждение «с голоса», «в реальном времени» хорошо при выборе пивной, а так ли оно нужно при обсуждении закона? Может, лучше немного подумать?
То, что обмениваются по почте неправильными текстами, это плохо. Но беспорядок не в почте, а головах. Вы думаете, они чатиться будут умными текстами?
Экономические последствия – это вообще отдельная тема. В большинстве случаев одни предлагают, считают совсем другие (просто по специализации). Кроме того, подсчет эффективности, выполненный отраслевым НИИ министерства-автора законопроекта, всеми будет критикуем как заказной и необъективный. 
Бизнес-практики плохо систематизированы – у нас свободная страна, кто хочет, пусть систематизирует. Государство систематизировало только небольшую часть в Уголовном и Налоговом кодексах.
Автоматизированный процесс от проблемы до закона попахивает Оруэллом. Замкнутый цикл управления описан в законодательстве от конституции и далее. Замена его на некий скрипт – тоталитарная утопия.
При этом в соцсетях (сужу по ФБ, ЖЖ) структура общения достаточно примитивна (я не про темы, а про сложность структуры). Заглавный пост – много постов в 2-3 уровня обсуждения и неконструктивные ответвления. Простая иерархия и,как правило, без итогового документа=результата дискуссии.
А уж справочно-правовые системы – вообще пример умной, структурированной, но жесткой структуры. Применительно к живым людям это откровенная коммунистическая утопия – почитать романы начала 60-х, наверняка что-то найдется.
Что можно и нужно делать: 
- отрабатывать взаимодействие людей (не компьютеров), повышать политическую культуру, культуру дискуссий, уважение к закону.
- аккуратно автоматизировать автоматизируемые вещи. 
- не питать иллюзий, что «вот будет программа, и все сразу станет хорошо» - не станет.

Решение Сергея Авдаляна, «Лаборатория Гемотест»:

1. Концепция: сквозное кодирование абзацев статей с индексами как номеров, так и ключевых понятий, причем при изменении номеров статей, коды и, соответственно, ссылочная целостность, должны сохраняться. Любое обсуждение, проект изменения, кейсы практического применения, должны обязательно привязываться к коду абзаца, причем сами обсуждения удобнее всего реализовать в виде тематических разделов веб-системы по типу социальной сети с возможностью создания рабочих групп, групп по интересам с указанием имеющихся навыков и экспертиз. В системе должны быть предусмотрены и запрограммированы типовые бизнес-процессы по обсуждению и принятию изменений.
2. Дорожная карта:
a. Оцифровать, структурировать и разместить в Базе данных все действующие законодательные акты.
b. Занести в базу всех будущих Пользователей системы с указанием их навыков и разделением прав и полномочий.
c. Внести в базу все принятые изменения в привязке к абзацам существующих документов и их историю за согласованный Заранее период (например, 10 лет).
d. Занести в систему все текущие изменения, находящиеся в процессе обсуждения.
e. Осуществить обучение пользователей навыкам работы в системе.
f. Принять дату, с которой все новые Проекты документов принимаются только в электронном виде в новой системе.

Решение Олега Зайковского, STEP UP International:

Disclaimer: Так случилось, что группа моих коллег и я имеем отношение к данной тематике как суб-подрядчики в части «выработки системы целевых показателей ИЭП (Инфраструктуры Электронного Правительства)». Поэтому я выскажу своё вполне компетентное мнение, не как специалист, а как гражданин данного государства.

1. Никаких «концепций и дорожных карт» придумывать и разрабатывать не надо. Если не ошибаюсь, это уже 4-ый заход к решению задач «электронного правительства» и «систем межведомственного электронного взаимодействия» (с реализацией «до 2010! года»). 
И уже выработан вагон, масса вполне грамотных схем, подходов, планов и т.п. Существует также достаточно примеров реализации таких систем, в частности, в Австралии, Великобритании, США (и т.д.), которые также были многократно осмыслены и учтены при разработке наших отечественных «кастомизаций».
См. в приложенных файлах - «Схема реализации электронного правительства в РФ (на примере ЦФО)» - egovcenter.ru – или Схему ИЭП (Инфраструктуры Электронного Правительства), опубликованную CNews. 
Существует также «Системный проект формирования в РФ инфраструктуры электронного правительства» Минкомсвязи (от 2010 г.), который сейчас и реанимируется с привлечением ФГУП НИИ «Восход», как генподрядчика, после передачи от «Ростелекома» в Минкомсвязи монополии на распил бюджета в этой его части.

2. Ответом на решение указанной задачи может быть только:
1. Жёсткая политическая воля руководства РФ – сверху донизу (что утопично априори);
2. Прозрачность организационной и финансовой схем реализации;
3. Постоянный контроль и мониторинг исполнения всеми «заинтересованными сторонами» и СМИ;
4. Публичная отчётность и реальная (любая: материальная, уголовная, гражданская) ответственность всех ЛПР по теме. 

Решение Светланы Бусуриной, ГК «Премьер»:

Я считаю, что основная причина такого состояния дел – отсутствие комплексного взгляда на бизнес-процесс и, как следствие, отсутствие «владельца» этого процесса, который и должен отвечать за его эффективность и оптимизацию.
На мой взгляд, правильный путь решения задачи – выделение предметных областей, систематизация обсуждаемых документов, привязка документов к предметным областям. 
Состояние каждой предметной области можно описать условной моделью, в которой выделяются ключевые параметры, изменение которых переводит предметную область в новое состояние.
Фактически для получения комплексной модели надо построить иерархию предметных областей с различными уровнями детализации в зависимости от уровня управления. Каждый уровень детализации предполагает свои ключевые параметры для управления — вот они-то и должны участвовать в математической модели, и использование прогнозных значений параметров управления должно давать прогноз состояния предметной области для конкретного уровня управления.
Нормативно-правовые акты существуют не сами по себе, а призваны регулировать деятельность их предметной области. Соответственно, можно и нужно определить параметры регулирования для каждой области и в итоге получить модель поведения предметной области при изменении тех или иных параметров.
В каждой области свои ключевые контрольные точки (параметры предметной области), и обсуждаемый документ обязательно должен быть «привязан» к связанным с ним предметным областям. Документ должен обязательно иметь привязку к ключевым параметрам предметной области, на которые он влияет (в идеале еще и меру влияния). Считаю, что только такое сопоставление позволит анализировать «сущность» документа с применением средств автоматизации.
Предлагаемый подход позволит прогнозировать влияние изменений на уже имеющуюся модель конкретной предметной области, а также «просчитать» изменение связанных с ней предметных областей.
Для работы над каждым проектом должна создаваться рабочая группа, включающая в себя все заинтересованные стороны. Заинтересованные стороны тоже разные – кто-то «владелец» предметной области» или эксперт, а кто-то выступает как «потребитель» или «заказчик», и каждая сторона имеет свой собственной весовой коэффициент, учитываемый при обсуждении. Естественно, мнение эксперта имеет больший вес, чем остальные.
Обсуждение должно быть конструктивным с обязательной привязкой замечаний к контрольной точке и предлагаемым изменениям контрольного параметра. По идее, правила подачи комментариев закрепляются межведомственным регламентом.
Таким образом, должна быть построена иерархия обсуждения и комплексная проверка предложений. Фактически речь идет о «корпоративной» структурированной системе документооборота и правилах работы с ней.
Что касается полезных технологий, то просто автоматизация без системного анализа и структурирования не помогут.
В целом для анализа, на мой взгляд, очень удобны Case средства (например Aris), а для подготовки материала для анализа, думаю, полезно использовать наработки компании 2Толк (www.2Talk.ru) по семантическому анализу имеющейся документации и компании Философт (www.philosoft.ru) для анализа целостности описания. Полагаю, что для первичной проверки модели не обойдется без технологий машинного обучения и искусственного интеллекта. Ну и раз уж мы говорим о системе документооборота, то каждая такая система использует свои технологии.

Решение автора кейса, Анатолия Белайчука, Chief Evangelist компании Comindware:

У этого кейса нет эталонного решения. Более того, предметом обсуждения (сюрприз!) здесь является не только решение, но и постановка задачи.
Задача цифровизации российской экономики в целом поставлена на государственном уровне, но здесь нет готовых рецептов – этот путь, который нашей стране предстоит пройти. Это относится и к цифровизации нормативно-правовой деятельности. На данном этапе заинтересованными министерствами в самом общем виде сформулирована потребность, но при этом есть понимание, что даже это высокоуровневое видение может быть ограниченным, и экспертов приглашают принять участие в его формировании. Определенно, это не та область, где уместна работа по традиционной схеме «вот вам ТЗ, идите, работайте!»
С точки зрения Comindware, нормативно-правовая деятельность в идеальном цифровом будущем выглядит так:
1. Сквозное сопровождение нормативно-правовых актов на всем протяжении его жизненного цикла, проходящего следующие фазы:
- Подготовка (выработка управленческого решения, оформление его в виде текста, согласование)
- Принятие (прохождение через законодательный орган, публикация, принятие подзаконных актов)
- Применение (частичная автоматизация судебного процесса на основе машинно-читаемых версий законодательных актов)
- Мониторинг и контроль (анализ воздействия на экономику, мониторинг реакции общества и СМИ)
- Корректировка (принятие решения о необходимости корректировки, инициация изменений/дополнений)
2. Система сбалансированных показателей РФ
- Финансовые (ВВП, развитие регионов и отраслей, уровень бедности и имущественного расслоения, …)
- Нефинансовые (продолжительность жизни, уровень преступности, уровень поддержки властей, …)
- Международные рейтинги (производительность труда, качество жизни, инвестиционная привлекательность, спортивные достижения, …)
3. Цифровая модель экономики
- Формализация хозяйственной деятельности через типовые бизнес-практики, понимаемые как системы сделок, характерные для определенного типа бизнеса в определенной отрасли
- Отнесение финансовых транзакций и экономической статистики к типовым бизнес-практикам, в т.ч. с помощью машинного обучения
- Экономико-статистический анализ и планирование в разрезе типовых бизнес-практик
- Имитационное моделирование изменения бизнес-практик и итоговых показателей под воздействием планируемого управленческого решения
Дорожная карта цифровизации нормативно-правовой деятельности может выглядеть так:
Этап I – то, что можно брать и делать, например, на основе Comindware Business Application Platform
Облачный сервис совместной законотворческой работы
- Реализация сквозного процесса законотворчества на основе стандартной нотации моделирования бизнес-процессов
- Разработка правовой онтологии
- Работа со структурированными документами (шапка, раздел, статья, пункт, …)
- Обсуждение в контексте шага процесса, в привязке к структуре документа, правовой онтологии и справочным правовым системам
- Доступ к актуальной версии     правового акта 24/7, к истории изменений, комментариям
- Квалифицированная ЭЦП
- Онлайн-редактирование
Машинно-читаемые версии законов
- на основе стандартной нотации моделирования бизнес-правил и языка выражений
Этап II – то, что требует предварительных научных исследований, в первую очередь в области экономики и статистики
Разработка цифровой модели экономики
- Формализация типовых бизнес-практик
- Реорганизация ОКОНХ и ОКВЭД
Экономико-статистический анализ 
- В привязке к типовым бизнес-практикам
- Интеграция с государственными информационными системами
- С использованием технологий машинного обучения
Этап III – то, что выходит за рамки эконометрики
Система сбалансированных показателей РФ
- Планирование целевых уровней
- Сравнение плана с фактом
- Принятие управленческих решений

Комментарии (4)

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Скрыть ветвь
    Рейтинг5090

    Старший-инженер

    Научно-производственное объединение

    12.07.2017 12:52
    Мне ближе всего решение Николая Матвеева.

    Имею опыт госслужбы не менее 10 лет. Прекрасно помню первые попытки внедрения безбумажных технологий (так это называлось) в советские времена. Принимал участие во многих современных попытках.
    Есть ли результат? Увы, результатов мало. Электронные системы стали существовать отдельно от гражданина, превратившись в удобный инструмент чиновника для быстрого реагирования на указания сверху. По сути, большинство подобных систем и конструкций успешно реализовали только одну функцию - контроль исполнительской дисциплины в рамках понимания того или иного чиновника. Как правило - контроль за своевременностью реагирования на проблему, но не контроль за её решением.
    Надо ли продолжать попытки электронного упорядочивания этого хаоса? Безусловно!
    Но Николай пишет и я так считаю, что тема пока не вышла за рамки философии. И не поменяв в корне подход госорганов к этой теме мы не приблизимся ни на шаг к заветной цели.

    Полагаю, что два постулата должны быть решены в будущей "ОГАС":
    - простейший доступ граждан к такой системе;
    - уж если применять бигдату, то именно к запросам граждан.

    Когда слышу фразу "дорожная карта", то весь интерес к разговору пропадает. Под дорожной картой наши работники госучреждений понимаю что угодно, но чаще всего обычный план работы без конечной даты.
    А сделать хотя бы элементарное: вернуться к срокам ответа на обращения граждан советского времени - 7 дней, если не запамятовал. Сейчас - 30.
    0
  • Скрыть ветвь
    13.07.2017 16:41
    Как автор кейса, должен покаяться - отдал его редакции Global CIO с корыстными целями, на халяву получить результаты такого своеобразного мозгового штурма. Спасибо всем участникам за вклад в решение поставленной задачи!

    Предложения крепкие, основательные, но... не слишком ли консервативные?

    Много серверов, специализированный клиент - мы в каком веке живем, извините? Облака, браузер, доступ с мобильного устройства - наше всё.

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

    Формализованный процесс, владелец процесса, организационное обеспечение - все это вечные истины, но разве вы не видите, как ИТ меняет окружающий мир? Не пользуетесь яндекс-такси и ЭМИАС, не работаете надо документами в google docs? Не скорректировали свой стиль вождения из-за повсеместного внедрения видеонаблюдения? ;) Суть цифровой трансформации - это мощнейший пресс со стороны ИТ, заставляющий целые отрасли менять модели ведения бизнеса. Это ведь удивительное явление: если раньше ИТ в основном следовал за потребностями бизнеса, то теперь зачастую он их формирует.

    Говорить, что была программа, которая должна была дать результаты еще в 2010 году... Я тоже могу вспомнить прожекты, которые рождались в Минавиапроме на излете социализма - я тогда работал в ЦАГИ мнс-ом. И что? В 2010 не было фейсбука и гуглдокса, сейчас есть. Люди, попробовавшие их на вкус, уже не будут другими.

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

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

    (Исправлено 13.07.2017 16:42, Белайчук Анатолий Анатольевич)

    0
  • Скрыть ветвь
    Рейтинг5090

    Старший-инженер

    Научно-производственное объединение

    13.07.2017 20:44

    Ответ на « Как автор кейса, должен покаяться -... »

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

    Уважаемый тезка!
    За покаяние - спасибо! Ваша попытка пробудить мозговой штурм удалась.
    Тем не менее, отвечу за щипок в мою сторону. С моей стороны это была лишь горькая ирония по поводу качества подготовки госкадров. Видимо иронии не поучилось и я стал цифровым эмигрантом из какого-то мифа. Этим мифы, видимо, сочиняют те, кто "i-штуки" освоил в младенчестве.

    Так как я даже не знаю, как идентифицировать "подлинные, прорывные инновации", то просто сделаю общий для себя вывод. Вы начали статью с конкретной задачи.- новая модель госдокументооборота, а закончили призывами догнать и перегнать... Я в Москве пользуюсь яндекс-такси. Отличный пример, когда технология не подменяет цель, а служит цели. Есть ли аналог яндекс-губернатора где-то в России? А в дальнем Подмосковье я стою несколько месяцев в очереди на получение электронного свидетельства на землю.
    Так как я не знаю, что такое "подлинные, прорывные технологии" и именно поэтому предложил начать просто бороться с хаосом, а потом его автоматизировать. Увы, в Ваших словах я не увидел новой модели.
    1
  • Скрыть ветвь
    Рейтинг870

    Начальник отдела разработки и сопровождения АСУ

    Нижегородский ИВЦ, структурное подразделение ГВЦ, филиала ОАО "РЖД"

    26.07.2017 12:42

    Ответ на « Как автор кейса, должен покаяться -... »

    Добрый день!

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

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

    3. В облаке, социальных сетях или еще где то ни чего само собой не появляется, все это тоже требует какого либо кодирования и размещения на каких либо ПТК. Тем более не все документы государственных структур могут публиковаться "не известно где", даже на этапе их подготовки.

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

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.