Документалистика

Документалистика — наука не о жизни документов и документальных систем.

Простейшее различение документалистики от информатики:

• управленец работает с документами;
• инженер работает с информацией.

Хранилища информации в СССР

• ИНИОН (информации по общественным наукам)
• ВИНИТИ (технической информации)
• ВНИИ (патентной информации)

См. также

• Документалистика КПСС
• ebXML

Несколько правил

Несколько правил документалистики и управления проектами из книги: Майкл Дж. Саттон. Корпоративный документооборот.

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

• Черновики отчетов - важные документы с точки зрения как истории, так и отчетности. Историк сможет проследить все тупиковые направления и непримиримые разногласия с помощью таких черновых версий документов. [104]

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

• Перед тем, как уничтожить документ или перевести его в другую категорию, следует уведомить об этом автора документа. [103]

• Поход к системе классификации файлов (карточек) с позиции направлений бизнеса (технологий) более гибок, нежели традиционная система распределения по отделам. [90]

• Спонсором проекта должен выступать хорошо информированный и заинтересованный представитель руководства организации, который может вложить в дело от одного до двух миллионов долларов и, пройдя через все препятствия, дождаться, пока это вложение окупится. Отсутствие такого спонсора предвещает провал всего начинания. [89]

• Конечному пользователю необходимо внушить уверенность, что документ, помещенный в электронное хранилище, всегда можно найти, даже без картотеки. Такое доверие не появится само по себе, и кроме того , оно требует времени. [75]

• Не начинайте разработку, если не хватает средств. [82]

• С точки зрения этики, лучшая позиция, которую может занять менеджер проекта СУД, состоит в том, что бы не начинать разработку, если отсутствует заинтересованность и возможность обеспечения ресурсами. [82]

• Трудно ожидать, что клиенты будут соблюдать четкий набор правил каталогизации документов, если даже сами разработчики не доверяют управление своими бумагами новой системе. [84]

• Постарайтесь ограничить количество членов команды разработчиков 5 - 7 сотрудниками. В этом случае внутренняя коммуникация в команде будет относительно простой, действенной и эффективной. [87]

• Разрабатывать концептуальную модель следует на основе сильных сторон старой системы и возможностей новой. [186]

• Создание СУД: либо все, либо ничего. Подобное начинание не терпит полумер. [188]

• Люди очень быстро находят в электронном пространстве обходные пути, позволяющие избежать бюрократических процедур и нерациональных подходов. [320]

• Не поручайте составление бизнес-проекта сотруднику организации который на этой не неделе не занят. Очень занятый человек лучше всего сумеет постигнуть суть бизнеса и больше других оценит систему управления документацией. Перераспределите ненадолго обязанности и поручите этому человеку разработку бизнес-проекта. [356]

Три основные причины запуска проекта разработки документации:

• • система может решить известную проблему;
  • система позволит компании осознать свои возможности в бизнесе;
  • система является частью стратегии предприятия. [360]

• Необходимо внимательно наблюдать за персоналом, чтобы уловить признаки внутреннего сопротивления переменам, непонимание новых процессов и неприятие системы. [379]

• Незначительная доля сотрудников предприятия (1-5 процентов персонала) так и не смогут адаптироваться к новым методам мышления в условиях работы с СУД. [384]

• Внедряя СУД (система управления документами) вы направляетесь совсем не туда, где были раньше. Вы строите новую цивилизацию на обломках старой. [254]

• В интерфейсе как пользовательского, так и серверного программного обеспечения очень важно использовать язык написания макросов и сценариев. [244]

• В любой корпоративной цивилизации существует функциональная археология, с помощью которой мы можем прорыть себе путь сквозь все слои, чтобы документировать существующие модели и представить детальную инфраструктуру всей системы в целом. [254]

• См. база знаний