Правила войны и систем - читать бесплатно онлайн полную версию книги автора (Правила Саттона электронного документооборота) #10

Правила Саттона электронного документооборота

[104Т] Майкл Дж. Саттон. Корпоративный документооборот.

Начало проекта

Satton_47

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

— система может решить известную проблему;

— система позволит компании осознать свои возможности в бизнесе;

— система является частью стратегии предприятия. [360]

Satton_23

Приступайте непосредственно к проекту только тогда, когда выясните, кто в конечном итоге будут отвечать за архивы СУД в Вашей компании. [81]

Satton_25

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

Satton_26

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

Satton_27

Проект который не обеспечен достаточным финансированием, изначально обречен на провал. [82]

Satton_28

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

Satton_33

Действия на этапе определения проекта СУД [88]

Satton_13

На фазе анализа получить одобрения от:

— менеджера будущих пользователей;

— менеджеров по управлению информацией и информационными технологиями;

— человека отвечающего за администрирование или управление записями. [89]

Satton_14

На фазе анализа составить список записей необходимых для составления плана восстановления бизнеса на случай чрезвычайной ситуации. [89]

Satton_15

Результаты фазы анализа:

— модели типов документов внутри заданной зоны документации;

— каталог объектов, характеризующих документы внутри заданной зоны документации;

— понятную, четко структурированную систему классификации. [89]

Satton_31

Результаты фазы определения:

— Одобрение или неодобрение плана и графика проекта;

— Список членов команды разработки;

— Распределение бюджетных средств, предназначенных для приобретения ресурсов и инструментария;

— Обоснование необходимых работ;

— Процедуры администрирования и управления проектом. [87]

Внедрение

Satton_55

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

Satton_3

Чтобы свести к минимуму риск и возможные негативные последствия для организации, СУД следует вводить сначала на уровне администрации и только потом в отделах, выполняющих непосредственные функции компании. [65]

Satton_4

Внедрение СУД следует осуществлять таким образом, чтобы у сотрудников была возможность внести свою лепту в достижение корпоративных целей. Пусть они примут участие в процессе изменений, получат в то же время необходимые знания и навыки в работе с технологиями управления документацией и разрабатывают новые методики использования СУД для принятия решений и обслуживания сотрудников компании. [113]

Satton_24

Выберите один из отделов компании, где вероятность успешного внедрения системы очень высока, и запустите там пилотный проект СУД. Необходимо найти очевидную проблему, которую можно будет решить при помощи СУД, и сотрудники выбранного отдела должны быть настроены на поиск этого решения, чтобы преграды, возникающие на пути внедрения СУД их не остановили. [80]

Satton_20

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

Satton_46

Важно обрисовать связанные с предлагаемым вложением в СУД зоны риска, возникающие по ходу внедрения системы. Основная идея состоит в том, чтобы факторы риска не скрывать. [357]

Satton_49

Первыми в очереди на установку системы должны стоять те отделы, где вероятность успеха наиболее высока. [365]

Satton_50

Если организация переходит на СУД, не осуществляя переработки процессов в ходе развертывания системы, то она лишь ускоряет набор нерациональных, выполняющихся вручную процедур; такое ускорение может начать работать против предприятия. [368]

Satton_51

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

Документы

Satton_5

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

Satton_7

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

Satton_8

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

Satton_9

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

Satton_21

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

Satton_22

Необходимо ввести единицу измерения качества документов хранящихся в архиве. Оценка качества дает возможность отделить информационные ресурсы предприятия от информационных помех. [75]

Satton_39

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

Классификаторы

Satton_1

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

Satton_2

Если клиент не может позволить себе затрат на разработку и поддержание системы в рабочем состоянии в полном объеме, то затраченные на тезаурус суммы окажутся выброшенными на ветер, и в конечном счете сама идея систем будет дискредитирована. [58]

Satton_18

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

Satton_30

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

Satton_35

Когда предприятие захлестнет волна нововведений, возникнут проблемы с неопределенностью и двойственной трактовкой терминов. Назначение архитектуры состоит в том, чтобы исправить эту ситуацию и создать мощную основу для перехода на СУД. [132]

Команда проектировщиков

Satton_45

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

Satton_48

Работающая над проектом СУД команда для хранения своих документов должна использовать средства СУД — она должна быть первой целевой группой, которая воспользуется преимуществами новой системы. [365]

Satton_32

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

Прочее

Satton_6

Только когда назначение политики станет ясным и понятным, его можно использовать как основу для приобретения предприятием ресурсов для СУД. [111]

Satton_10

Разработайте методику оценки соответствия системы потребностям пользователей для контроля и анализа работы системы. [99]

Satton_11

Необходимо позаботится о том, чтобы не оказались нарушенными авторские права создателей материалов которые вы собираете. Следует организовать систему проверки законности использование материалов, защищенных авторским правом, и разработать структуру их дальнейшего распределения среди сотрудников организации. [97]

Satton_12

Создать список процедур, которые обеспечат неразрывность объектов оригинала документа и системной информации о нем в хранилище. [96]

Satton_16

Результаты фазы создания документов (сбор, перевод в формат, отцифровки которые войдут в СУД):

— полный список внешней документации компании;

— полный список документов унаследованных от старой системы;

— полный список авторизованных документов компании. [92]

Satton_17

Результаты фазы сохранения документации:

— защищенное хранилище (репозитарий) документов;

— система определения подлинности и авторизации;

— контроль версии документов и возможность проведения проверки. [95]

Satton_19

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

Satton_29

Попытка сократить сроки осуществления проекта на 50% процентов обычно приводит к тому, что реальная разработка заканчивается на год или два позже, чем было запланировано. [83]

Satton_34

Разработка СУД — не лучшее время для обучения по ходу работы. [122]

Satton_36

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

Satton_37

Если не провести детальную инвентаризацию документов, возлагать ответственность за потери на администратора записей совершенно невозможно. [187]

Satton_37

Разрабатывая модель СУД, необходимо найти возможность убрать все организационные стены и включить в систему все направления бизнеса организации без учета структурных подразделений. Новая система должна основываться на всеобъемлющем подходе и принимать все записи и документы, созданные или собранные сотрудниками компании, объединяя тем самым различные направления бизнеса фирмы. [188]

Satton_38

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

Satton_40

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

Satton_41

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

Satton_42

Положительный эффект использования СУД особенно заметен во время реорганизаций. [321]

Satton_43

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

Satton_44

В удачном бизнес-проекте должно быть предусмотрено снижение затрат как минимум на 20 процентов. [353]

Satton_52

Основной фактор риска, возникающий в процессе работы, — кратковременное падение эффективности. [381]

Satton_53

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

Satton_54

Если сотрудники каких-либо подразделений имеют шанс потерять работу, директор проекта не должен им лгать. [384]

Satton_56

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

Satton_57

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

Satton_58

Программное обеспечение само по себе представляет область значительного риска. (Приложение трехлетней давности можно считать достаточно старым, пятилетней давности и старше — очень старым (если это не касается инженерных средств (например KEE, dBASE V) которые заблокированы из колониальных соображения А.В.). Если программе меньше двух лет, то есть риск того, что в ней еще остались неисправленные ошибки или не протестированные области.) [421]