Всегда присутствует соблазн сразу же выбрать автоматизацию. Это нормально для людей, работающих с информационными технологиями. Проблема в этом случае заключается не в самом выборе, его преимущества не обсуждаются, а в реализации. На уровне дизайна новой системы согласования (будь то веб-голосовалка или сложная система документооборота) очень трудно предугадать все возможные изгибы и нюансы будущего процесса. От этого возрастает риск возникновения необходимости внесения изменений в приложение, как на поздних стадиях разработки, так и в процессе эксплуатации. Это не составляет сложностей, если в компании имеется собственный отряд программистов, обученных тонкостям итеративных моделей разработки и дисциплинированно соблюдающих правила контроля за изменениями. Но если честно, я таких чудес еще не встречал. Поэтому я предлагаю быть реалистами и комбинировать используя оба подхода: бумажный и компьютеризированный.
Реализуйте процесс или решите проблему "хоть как-то": с использованием наличествующих средств и в кратчайшие сроки. Например, в том же бумажном варианте. Попользуйтесь процессом какое-то время, выявите все (или большинство) недостатков изначального дизайна, измените "бумажный" процесс в соответствии с обнаруженными нюансами. Когда процесс наладится и проблемы станут возникать значительно реже, приступайте к автоматизации. Но не забудьте учесть такие детали, как платформа реализации, образованность пользователей и нюансы корпоративной культуры.
Практическое наблюдение: так зачастую получается лучше и быстрее всего. Правда, на ранних этапах выполнения "бумажной" версии процесса есть одна неприятная деталь -- недовольство участников. Практически всех их придется убедить в пользе выбранного комбинированного подхода. Как правило, получается: на лицо экономия средств (программирование, вообще-то, штука не дешевая, даже на аутсорсе) и времени. Зато представьте сколько нервов вы сэкономите в будущем: не придется ввязываться переписку и непрекращающиеся встречи с проектными менеджерами и архитекторами, все выясняя, обновляя, детализируя и согласовывая детали реализации проекта (при этом не получая никакой гарантии, что вас поняли правильно). Ведь он уже реализован и обкатан вами в боевых условиях.
А главное -- представьте, с какой радостью пользователи встретят новый, накрашенный и причесанный автоматизированный процесс!
Изложенный метод легко экстраполировать не построение не процессов, а систем или нового функционала. Пример: нужно выбрать и установить систему обнаружения вторжений. Пред тем, как начинать оценку решений, предложенных на рынке вендорами в супер тяжелой весовой категории (Cisco, McAfee etc.), установите временно какое-нибудь open source решение и понаблюдайте над тем, что творится в вашей сети. Это можно сделать быстро: все необходимое уже есть в наличии. Не придется ждать заключения договоров на опытную эксплуатацию, доставки демонстрационного оборудования (45 рабочих дней, да?), его растаможки, установки в и без того перегруженную серверную...
Поэкспериментируйте с расположением сенсоров в различных сегментах, прикиньте где они нужнее, а где от них нет никакого толку. Например, ставить IDS на внешнем канале Интернет, между вашим пограничным маршрутизатором/межсетевым экраном и сетью провайдера, особого смысла не имеет -- об уровне угроз в глобальной сети можно и в прессе почитать. Вдоволь налюбовавшись отчетами и выстроив в голове более четкий набор требований к решению промышленного уровня, приступайте к его выбору. И заметьте, в период тендера, оплаты, доставки и внедрения мега-крутого IPS от заокеанского вендора (а это может затянуться на месяцы), у вас будет действовать пусть скромное и временное, но все же решение проблемы.
