Как установить сэд на компьютер
В крупных и средних компаниях рано или поздно возникает потребность в системе электронного документооборота, т.к. следить за бесконечно растущим количеством документов становится совершенно невозможно. И в 90% случаев первая попытка внедрения становится большой болью в сердце и где-то ниже, хотя её можно было бы избежать. Причём избежать можно как той самой боли, так и вообще внедрения, если вы поймёте, что пока не готовы к нему, и сможете это аргументировать.
Как сотрудник компании, внедряющей СЭД, я бы хотел поделиться неким чек-листом того, что стоит сделать до внедрения, чтобы по его итогам вас не уволили. Итак:
1. Определите уже цель!
Сколько проектов завершилось взаимной неудовлетворённостью между заказчиком и внедренцем, потому что первый хотел светлого будущего, а второй пытался сделать блестящее настоящее (ну или наоборот). До того, как даже начать обсуждать с кем-либо проект внедрения, поймите какая у вас цель. Чего вы хотите добиться этим проектом? В принципе, для первого раза подойдёт любая наболевшая проблема, которую хочется решить. Ваши сотрудники периодически теряют документы? Сделайте целью контроль за бумажной версией. Все забывают вовремя выполнить поручения, связанные с документом? Давайте усилим контроль за исполнением. И т.д.
Что будет, если не сделать:
Во-первых, вы получите звездолёт, который не летает: куча кнопочек, куча окошек, тьма отчётов, но нафига всё это нужно, никому не ясно: ведь лучше-то не стало!
Во-вторых, умный подрядчик заменит ваши настоящие цели на легко достижимые для себя и максимально эффектно выглядящие. Если он умеет делать красивые отчёты, то в системе будет 100 отчётов, показывающих сколько раз в день сотрудники подумали про документ, который продолжает подпирать ножку шкафа вместо того, чтобы лежать на столе у генерального директора.
И ещё: сократите количество целей до минимума. Иначе вы получите СЭД по цене звезды смерти.
2. Выразите цель в цифрах
Это, в принципе, касается любых целей в любых областях жизни. Нельзя ставить цель: «похудеть», потому что такая цель не имеет «тормозов» и точек для оценки успеха. И вы или останетесь толстым, или превратитесь в анорексика. Так и с документооборотом, не ставьте цель «более лучше одеваться контролировать исполнение» или «быстрее согласовывать документы». Сформулируйте точнее, например: «сейчас мы отвечаем клиентам на их письма с задержкой в месяц, надо отвечать в течение двух недель. Или отнимать печеньки у исполнителя, если не успел».
Что будет, если не сделать:
Вы придёте к тому будущему, которое кажется светлым внедренцу. А, как известно, кому-то и могила в радость.
3. Найдите владельца процессов
Вот это моё любимое! Если требования к какому-либо процессу могут предъявлять любые отделы и сотрудники, то вы дальше технического задания на настройку не уйдёте. Каждая попытка создать единый процесс будет упираться в мерянье половыми органами руководителей отделов на предмет того, чьи проблемы критичнее. Будет создаваться чёткое впечатление, что все эти люди работают в разных конкурирующих компаниях и стараются поглубже закопать конкурента.
В идеале у каждого процесса должен быть один владелец, который любые споры может прекратить фразой: «Потому что я так сказал», — и никто не сможет ему возразить. В компаниях, работающих по ISO 9000, логичнее назначить владельцем СМК. В других же — для каждого процесса наиболее штрафуемую в случае факапов службу: для договоров — юристы, для первички — бухгалтерия и т.д.
Что будет, если не сделать:
Вы посмотрите поставленную за счёт вашей компании басню «Лебедь, рак и щука», главные роли в которой будут исполнять директора департаментов. И, если подрядчик в конце концов напишет техзадание, то в нём будет 500 страниц, а стоимость внедрения опять приблизится к звезде смерти.
4. Определите «спонсора» проекта
- Будет готов своим именем защищать проект;
- Сможет заставить всех работать в системе;
- Достаточно прочно сидит на своём месте.
Что будет, если не сделать:
Вы получите СЭД, в которой никто не работает, и которая лежит «мёртвым грузом». А если не выполнить пункт про «прочность сидения» руководителя, то будет бинго! Системой не пользуются, спонсора проекта уволили, вы восхитительны!
5. Решить: вы или вас?
И вот пришло время погрузиться в детали. По какому пути вы пойдёте: быстрое и дешёвое внедрение «коробочного решения» или долгая и дорогая разработка под вас. В чём разница? Если вы спросите у лесничего, как быстрее добраться до другой стороны леса, то он вам точно подскажет короткую тропинку. Но если вы в этот момент передвигаетесь на феррари, то логичнее выбрать шоссе, ведущее в обход, пусть и длиннее на несколько сотен километров. Поясняю: коробочные решения любого внедренца — среднестатистическая функциональность, которая подходит любой компании в теории, и позволяет достаточно быстро и дёшево развернуть её на вашей территории. Если денег мало, то позвольте подрядчику «причесать» ваши процессы под коробку. Но если ваши процессы исторически сложились определённым образом и помогают компании максимально эффективно существовать, а с бюджетом проблем нет, то даже не пытайтесь натянуть «коробку» на себя.
Что будет, если не сделать:
Если у вас мало денег, то не суйтесь в персонализированные решения: стресс будет неподъёмным, а результат вас разочарует, даже если вы раскошелитесь на дорогостоящий проект. Вы никогда не поймёте, почему ЭТО столько стоит?
Если же вы обладатель уникальных процессов, то внедрение коробочного решения выставит внедренца дурачком и вас, если вы будете пытаться занять его позицию: ведь что это за «кастрированная» функциональность? Как может существовать система без цветовой дифференциации штанов?
6. Живите настоящим
Сколько раз я встречал требования в ТЗ к договору: 4000 одновременно работающих пользователей, 12 серверов в кластере, плановая нагрузка 1 млрд документов в год, а по факту в конце внедрения в системе работает 100 человек, которые заводят по 3 документа в день. Если вы планируете похожей нагрузки достичь только года через три, то лучше сделайте внедрение сейчас и заложите масштабирование через пару лет.
Что будет, если не сделать:
Во-первых, ценник опять будет приближаться к галактическим масштабам. Во-вторых, вы и подрядчик потратите кучу времени и сил на настройку того, что даже проверить не сможете. Никакие синтетические тесты и нагрузочные испытания никогда не покажут поведение системы под реальной нагрузкой. Закон Мёрфи никто не отменял. А где через три года будет подрядчик, который вам внедрил систему, неизвестно. Да и по законам РФ срок гарантии на системы — 2 года.
7. Здраво оцените сроки
Единственный пункт, который напрямую затрагивает меня, как подрядчика. Прислушайтесь к советам по поводу сроков внедрения. Не доверяете мне, спросите у пары других специалистов (тоже, кстати, универсальный совет). Если все вам говорят, что нельзя такой объём работы сделать быстрее чем за полгода, то, значит, так и есть. И никаким вливанием денег вы этот вопрос не решите.
Что будет, если не сделать:
К концу проекта вы получите нечто из костылей и велосипедов, держащееся на соплях и позволяющее кое-как пройти приёмочные испытания. А дальше в течение оставшегося срока подрядчик будет плавно допиливать не допиленное, доделывать не доделанное и ускорять не ускоренное.
«Любая инсталляция системы должна начинаться с чтения инструкции», — сказал бы инженер и выбросил мануал в окно. На этапе установки любой ИТ-системы возникает множество вопросов, на которые не может ответить ни одна инструкция, даже очень хорошая. Установка системы электронного документооборота (СЭД) не является исключением. У разных технических специалистов есть своя наработанная база в части работ по инсталляции продуктов. В этой статье речь пойдет о практиках, которые годятся для любой системы электронного документооборота и, в частности, о практиках инсталляции LanDocs.
До начала внедрения СЭД необходимо решить важные задачи: подготовить всю инфраструктуру и установить программное обеспечение, необходимое для работы системы, затем обеспечить доставку приложения на персональные станции пользователя. Далее следует стандартный этап эксплуатации и регулярного обновления продукта.
Первый шаг любого администратора — запросить у производителя технические требования к оборудованию и программному обеспечению, которое требуется для работы внедряемой системы.
После получения технических требований и анализа собственной инфраструктуры многие заказчики приходят к пониманию того, что самым оптимальным является создание виртуальных машин для работы систем электронного документооборота. Это позволяет снизить затраты на покупку отдельных физических машин и, конечно же, в дальнейшем помогает в администрировании системы, так как обслуживать приходится фактически один или два физических сервера, на которых развернуты все решение.
Следующим шагом после подготовки серверов/виртуальных машин и установки на них операционных систем по требованию вендора является инсталляция системы управления базами данных (СУБД). Перечень СУБД, с которыми работают СЭД, разнообразен, но чаще всего используются СУБД MS SQL и СУБД PostgresPro. Оба производителя предлагают бесплатные версии своих СУБД (Express и Vanilla соответственно) с определенными ограничениями, но, учитывая объем данных и требования к системам, для сегмента средних и малых организаций их, как правило, вполне достаточно. Мы в своей практике предлагаем взаимодействие с обеими СУБД, что снижает затраты на внедрение.
Любой производитель СУБД имеет ряд рекомендаций к настройкам после инсталляции, и надо им обязательно следовать, поскольку чаще всего они относятся к быстродействию системы в целом. На основе практики крупных внедрений и внедрений в средних и малых компаниях мы подготовили четкий сценарий настроек СУБД. Так, настройка СУБД MS SQL Express содержит следующие необходимые шаги.
Являясь рабочим пространством для хранения временных объектов, база данных (БД) TempDB активно используется системой.
Добавление нескольких вторичных файлов данных позволит ослабить конкуренцию при выделении и освобождении страниц в TempDB. Необходимо добавить или создать нужное количество файлов данных БД TempDB из расчёта: суммарное количество равно половине числа ядер процессора на сервере СУБД (4 ядра — 2 TempDB, 8 ядер — 4 TempDB, и т.д.), при этом нужно оставить только 1 файл транзакций.
При добавлении вторичных файлов данных следует устанавливать для всех файлов данных одинаковый начальный размер и размер приращения (в фиксированной величине в МБ).
Настраивать конфигурацию TempDB следует, используя следующие рекомендации:
• каждый файл данных — начальный размер 2ГБ, размер приращения — 512МБ;
• журнал транзакций — начальный размер 2ГБ, размер приращения — 512MБ.
Для улучшения производительности дисковой подсистемы рекомендуется отформатировать диски с размером кластера 64 КБ.
На данный момент диски для продуктивной системы отформатированы с размером кластера 4 КБ. Увеличение размера кластера до 64 КБ в соответствии с рекомендациями производителя позволит ускорить выделение свободного пространства и уменьшить нагрузку на диски. Данную рекомендацию стоит выполнять, если есть возможность отформатировать диски, перенести файлы баз данных и настроить их на новое расположение.
• TF 4199 — управляет несколькими изменениями оптимизатора запросов, внесенными
ранее с несколькими флагами трассировки;
• TF 1117 — для одновременного выполнения операции приращения всех файлов БД (с несколькими файлами данных) — актуально для TempDB;
• TF 1118 — удаляет большинство одиночных размещений страниц на сервере, уменьшая вероятность конфликтов блокировок на странице SGAM.
Рекомендуется также рассмотреть и протестировать возможность включения в продуктивной среде флага трассировки TF 2371. Данный флаг трассировки позволяет использовать динамический порог для обновления статистики.
Изменение обязательно должно выполняться через SQL Server Configuration Manager, а не через консоль управления сервисами ОС.
1. В свойствах SQL Server установлена опция «max degree of parallelism» в 1, таким образом отключен параллелизм;
2. Для учетной записи SQL Server настроены следующие политики:
• политика Perform volume maintenance task (выполнение задач по обслуживанию томов). Данная политика позволит аккаунту SQL Server при необходимости производить «мгновенное» приращение на файлах данных БД. Политика не работает в отношении файлов журнала транзакций;
• политика Lock Pages in Memory (блокировка страниц в памяти) позволяет предотвратить усечение памяти, управляемой SQL Server.
После установки необходимых разрешений в Local Policy необходимо перезапустить службу SQL Server.
3. В свойствах базы данных LD установлена опция «Is Read Committed Snapshot On» в 1 (True).
Отдельные рекомендации могут не применяться в зависимости от СЭД, но в основном эти настройки подходят для всех часто используемых систем документооборота.
После полной подготовки инфраструктуры и настройки серверов установка самого решения занимает считанные минуты, поскольку все производители предоставляют или преднастроенные инсталляционные пакеты с запросом на этапе установки минимальной информации (имен серверов, базы и т.д.) или инсталляторы, которые все разворачивают в бездиалоговом режиме.
Публикация веб-версии обычно не вызывает трудностей, а установка клиента на ПК пользователей для многих сложна. Крупные компании для решения этого вопроса используют доменные политики, различные программы для публикаций приложений, а в средних и малых организациях чаще всего нет такого программного обеспечения, и администраторам приходится устанавливать систему на каждый компьютер вручную. Это длительный и трудоемкий процесс, который не гарантирует идентичных настроек системы у различных пользователей, что влияет на эксплуатацию.
Мы в своей практике применяем более технологически простое и удобное решение — публикацию приложения по технологии Click Once. Администратору достаточно по инструкции подготовить на сервере комплект установочных файлов и разослать ссылку любым удобным способом на сетевой ресурс или существующий в организации портал. Наличие или отсутствие домена, прав пользователя на ПК никак не влияет на установку приложения.
Таким образом, установка приложения на персональные компьютеры пользователей сейчас является достаточно простой и быстрой задачей. Главное — внимательно ознакомиться с документацией, которую предоставляет вендор.
В части эксплуатации и обновления системы любой администратор должен решить два вопроса, которые позволят предоставлять услугу для бизнеса в бесперебойном режиме: как и за какими данными необходимо следить, чтобы избежать аварии и своевременно найти предвестника инцидента, и как быстро и безболезненно установить обновление.
Практически все производители СЭД предоставляют описание данных, которые требуется регулярно сохранять. Чаще всего это базы или база данных, образы самих документов в системе и исполняемые файлы. Далее каждый администратор выбирает инструментарий для создания резервных копий необходимых для работы данных. Выбор того или иного метода зависит от двух показателей, которые должен указать бизнес-заказчик. Это максимальный период времени, за который могут быть потеряны данные в результате инцидента (RPO, recovery point objective), и время, в течение которого система может оставаться недоступной в случае аварии (RTO, recovery time objective). В зависимости от этих показателей администратор принимает решение, достаточно ли ему будет резервных копий баз данных и файлов или необходимо делать копии всех виртуальных машин, на которых развернута система. Главное в этой задаче — обеспечить минимальное время простоя и, конечно же, постараться потерять минимальный объем данных.
Сами системы, проверенные годами, вряд ли приведут к сбою и потере данных, а вот инфраструктура всегда была и остаётся узким местом. Поэтому рекомендуется сохранять полные образы базы данных и файлов не реже раза в сутки, а в течение рабочего дня делать так называемые инкрементные бэкапы. Что касается самих исполняемых файлов, их потеря не критична, так как можно за несколько минут их установить повторно. В любом случае имеет смысл запросить регламенты резервного копирования и восстановления у производителя.
Немаловажный фактор обеспечения эксплуатации — ежедневный мониторинг за показателями системы. В зависимости от сложности настроенных процессов, интеграционных модулей и много другого мониторинг может проводится раз в день, к примеру, утром, или же три раза в день. В данном случае критерии проверки бизнес модулей устанавливает сам заказчик. Мы со своей стороны можем дать только технические рекомендации: какие службы требуется проверять, какие показатели являются нормой и как правильно анализировать лог-файлы для выявления предвестников инцидентов.
Периодичность и порядок обновлений системы зависят от производителей. Для крупных внедрений мы рекомендуем планировать обновления не реже двух раз в год, для решений сегмента малого и среднего бизнеса обновления достаточно проводить раз в год. Процесс обновления LanDocs очень прост: необходимо запустить инсталляционный пакет в режиме «Обновить» на серверах, где установлена система, и компоненты будут обновлены до последней актуальной версии. Единственное, что останется администратору, — это собрать Click Once для клиентов, и при старте системы на клиентских местах будет обновлено и клиентское приложение.
В целом, это основные моменты, на которые стоит обратить внимание при внедрении СЭД любого производителя. И самое главное, любой администратор должен понимать, что после внедрения он не остается один на один с системой, у него есть техническая поддержка производителя и компании-поставщика.
Читайте также: