По-третє, ефективне автоматизоване УДП в ЭТДО можливо тільки при крізній інтеграції потоків робіт і документів між всіма додатками, що здійснюють УДП. Це сама по собі надзвичайно складне завдання, процес стандартизації якої почався зовсім недавно (перші стандарти з'явилися в 1999 році) і активно продовжується коаліцією Workflow Management Coalition. Ці стандарти поки реалізовані у вельми невеликій кількості продуктів таких відомих розробників, як SAP AG, BAAN, IBM і деяких інших. На жаль, наші розробники засобів управління документообігом цим похвалитися не можуть, та зате багато хто декларує «відповідність вимогам стандартів і принципів створення відкритих систем». Максимум, що пропонується нашими розробниками — точкова інтеграція між окремими засобами УДП, заснована на приватних нестандартних специфікаціях обміну. Відмітна особливість цих специфікацій — опора на поточні програмні реалізації продуктів де-факто (тобто в кращому разі — на внутрішньофірмові стандарти виробників, в гіршому — на логіку розробників програмного забезпечення). Рішення на базі таких інтеграційних рішень звичайно «сыпятся» при переході на нову версію продукту або при зміні опорних технологій, і на всі сто процентів залежать від розробника.

Міф 4. Cодержание паперових архівів обходиться підприємствам на 80% дорожче, ніж архівів електронних.

Можливо, якщо справа стосується архівів нетехнічних документів. Що ж до архівів технічних документів, то говорити про вартість їх змісту поки що рано. Спочатку непогано було б прорахувати, в що виллються вкладення в разові роботи: обстеження підприємства, проектування і створення програмно-технічного комплексу, оцифрування паперового архіву, розробка системи управління застосуванням ЭЦП, розробка нової технології роботи і регламентів роботи з ЭТД, гармонізацією з системою традиційного документообігу, навчанням персоналу, переходом на нову технологію. Додайте сюди специфіку електронних архівів, описану в другому міфі, в скільки обходяться штатні і позаштатні затримки при супроводі програмно-технічного комплексу з його вельми частими змінами...

Міф 5. Впровадження ПО документообігу робить діяльність співробітників прозорішої, а значить і більш керованої.

Керованість є міра досяжності поставлених цілей за рахунок впливу керівників на виконавців, на зміну технологій бізнесу і процесів бізнесу, і вже ніяк не є слідством прозорості діяльності персоналу і не залежить від електронних систем. Кожен рівень управління в ідеалі повинен займатися своїми справами, а не розбиратися, чому не працює більш нижній рівень (хоча є немало керівників, що із задоволенням підміняють виконання своїх основних завдань виконанням завдань нижнього рівня). Практика переконливо доводить, що керівництво все менше і менше має можливостей для обдумування і ухвалення навіть стратегічних рішень. Це ще раз доводить, що управління людьми розвиватиметься у бік «чорного ящика», коли важливий результат, а не процес. Що ж до технологій бізнесу, те грамотне впровадження ЭТДО в сукупності із створенням і впровадженням автоматизованої системи управління процесами бізнесу дійсно може дати ефект прозорості бізнесу, тобто можливість бачити технології бізнесу і процеси бізнесу на різних рівнях їх уявлення, ефективно управляти ними і змінювати їх. Це надзвичайно важливе завдання, оскільки технології проектування і створення виробів в електронному вигляді тільки починають створюватися.

Система управління технічним документообігом: кішка, яка гуляє сама по собі?

Історично склалося так, що технічний документообіг і його автоматизація ніколи не розглядався ні як самостійна дисципліна, ні як комплексна система управління. Були і є стандарти ЕСКД, ЕСТД і інших груп, галузеві стандарти, в яких технологічні, організаційні і процедурні питання, пов'язані з технічною документацією і документообігом досить добре відпрацьовані і перевірені десятиліттями. Сама ж система управління була «человеко-орієнтованою» і що надзвичайно важливо — інтелектуальної (оскільки засобом всіляких операцій над документами, засобом інформаційної взаємодії, засобом дозволу колізій була і є єдина інтелектуальна уніфікована природою «обчислювальна машина» — людина). Це дозволяло вирішувати задачі управління документообігом фактично у фоновому режимі при збереженні слабо формалізованої інформаційної взаємодії його учасників. Таке положення справ довгий час залишалося незмінним під час автоматизації систем створення і підготовки інженерних даних. Це підтверджує і той факт, що категорії Docflow і Workflow з'явилися не у вигляді самостійних систем, а як допоміжні модулі до різних систем PDM, ERP і САПР і додаткам бізнесу.

Така втрата самостійності ЭТДО і сьогодні грає злий жарт з вітчизняними підприємствами: замість створення сучасних систем управління документами і діловими процесами підприємства як і раніше концентрують свою увагу на завданнях створення і підготовки вмісту документів (технічних даних). Методи і засоби управління документообігом фактично опинилися без змін. Таким чином, завдання автоматизації управління ЭТДО фактично є придатком систем створення і обробки електронних технічних даних. В результаті не використовується один з найважливіших інструментів, здатних вплинути на технології бізнесу, зокрема на перехід до процессно-орієнтованої організації бізнесу.

Електронний технічний документ: візьми те, не знаю що...

Стандартів на електронні технічні документи (ЭТД) в Росії поки не існує. Та і сама система стандартизації електронного документообігу будується вельми нелогічно: розробляються приватні системи стандартів, що охоплюють деякі приватні області його застосування (наприклад, стандарти STEP, стандарти серії ГОСТ Р ИСО 10303 і ін.), в той час, як немає основоположних загальносистемних стандартів на електронний документ, системи управління електронною документацією і системи управління електронними даними. Таким чином, навіть в такій системній справі, як стандартизація, ми продовжуємо «славну» справу клаптевих рішень.

В даний час розробку стандартів на систему управління електронною технічною документацією веде науково-дослідний центр CALS-технологій «Прикладна логістика» (). Автору довелося бути розробником проекту стандарту на систему