Как стать автором
Обновить

Открытые технологии в электронном документообороте

Время на прочтение 4 мин
Количество просмотров 1.5K
Давным-давно говорят люди об электронном документообороте. Только вот до сих пор (для примера) в моём офисе для подготовки одного документа 2–3 листа бумаги уходит на черновики.

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

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

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

Итак, что же я предлагаю?


  1. Решение.
  2. Применение.


Решение: OpenDocument + Subversion + Визуализатор diff + Trac



  1. Формат OpenDocument (ODF).
    Формат офисных документов различного рода. Применяется в открытых офисных пакетах OpenOffice.org, StarOffice и других.
    Особенность формата с точки зрения разработчика заключается в том, что каждый документ представляет собой архив, основную часть которого занимают файлы в формате XML. Архив распаковывается «на лету», а файлы XML легко поддаются программной обработке.
  2. Система управления версиями Subversion.
    Системы управления версиями (СУВ) используют для хранения многих версий одного документа так называемое разностное сжатие (иногда встречается термин дельта-компрессия, или Δ-компрессия). Благодаря разностному сжатию в специальном хранилище — репозитарии — откладываются файлы не целиком, а лишь различия между версиями.
    Эти различия обычно вычисляются при помощи программы diff (от англ. difference — различие). Пользователь СУВ в любое время может сравнить любые версии документа, узнать, какие правки вносились им и другими пользователями,
    вернуться к какому-либо из предыдущих состояний документа.
  3. Визуализатор diff.
    У старой, как компьютерный мир, утилиты diff есть 2 существенных недостатка. Во-первых, она рассчитана на построчное сравнение текстовых файлов, что может оказаться неоптимальным для поиска различий в файлах XML.
    Во-вторых, насколько непохож документ ODF в режиме редактирования на свой исходный XML-код, настолько же непонятен конечному пользователю вывод diff. Для эффективной работы пользователю необходимо наглядное представление различий между версиями.
    Пожалуй, это единственный компонент предлагаемой системы, требующий серьёзного приложения усилий.
    Возможные пути решения задачи:
    • обработка вывода «классического» построчного diff;
    • доработка или создание нового diff для более корректного сравнения XML-файлов и упрощения визуализатора.


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


Применение



Рассмотрим теперь механизм работы всей этой связки.

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

Возьмём, к примеру, такую ситуацию: начальник филиала некоторой фирмы даёт задание какому-то отделу подготовить годовой отчёт. Для этого он

  1. заходит на корпоративный вебсайт, в СУЗ;
  2. создаёт в ней задание;
  3. задаёт атрибуты задания:
    • срок выполнения задания;
    • важность;
    • срочность;

  4. назначает исполнителя задания — начальника отдела.



Задание введено в систему и автоматически отправлено начальнику отдела по электропочте или с использованием корпоративной системы мгновенного обмена сообщениями (СМОС, IM).

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

Каждый сотрудник пишет свою часть отчёта и время от времени отправляет её на сервер управления версиями.

Для этого есть множество готовых решений, но для пущего удобства пользователя можно даже написать плагин к OpenOffice.org и другим офисным пакетам.

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

По окончании подготовки отчёта исполнитель — начальник отдела устанавливает состояние задания в «выполненное».

Если начальнику филиала по каким-либо причинам не понравится выполнение задания, он может снова сделать задание активным (с указанием причины).

UPD. Спасибо Outspector за содержательный комментарий. Он напомнил про такую важную проблему, как слияние версий, и предложил использовать LATEX для подготовки документации. Стоит согласиться с ув. Outspector по поводу полезности LATEX для специалистов, но хорошее решение для «секретарш» пока не найдено.
Теги:
Хабы:
+6
Комментарии 26
Комментарии Комментарии 26

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн