вторник, 29 октября 2013 г.

Какими навыками должен обладать специалист по автоматизации? Интересно?

Сегодня мне пришлось задаться этим вопросом.

Вам когда-нибудь приходилось внедрять процесс автоматизации организационных процессов с нуля? А применяя научный подход? И при этом взаимодействовать с заказчиком (руководителем подразделения) абсолютно "из другой области, отличной от технической"? Когда заказчик еще и хочет не только получить результат, но и активно участвовать, ставить задачи и контролировать работу? Нет?! Странно...

Но кроме шуток, мне пришлось с этим явлением столкнуться. Руководитель (заказчик) не может (или не хочет) довериться специалистам, контролировать сроки и ожидать результат, он хочет вникнуть во все детали.. быстро вникнуть.. за час-два где-то, чтобы уже вами командовать самостоятельно, а не просто доверять вашему профессионализму. Ну, чтож, похвально. Вот, только для этого мне необходимо "обучить" заказчика основам автоматизации, а именно из чего строится весь этот непростой процесс, и какие знания и навыки при этом необходимы.

Вот, что у меня получилось.

В любой автоматизации есть несколько ролей: крайне редко бывает так, что один человек совмещает несколько из них или даже все. Это роль:
  • заказчика
  • системного аналитика
  • программиста
 Заказчик является носителем знаний о функционале, который необходимо автоматизировать. В лучшем случае он даже представляет себе детально процесс. В худшем - знает как работать "как-то так, как получается", не выстраивая особо каких либо логических последовательностей выполнения работы, не утруждая себя причино-следственной связью между действиями участников процесса. 

В классической модели заказчик должен предоставить формальное описание бизнес-процесса в виде схем (нотаций схем бизнес-процессов множество, их выбирают в каждой организации "под себя", что удобней). Но, как правило, это тоже редкость.

Системный аналитик по предоставляемым схемам пишет составляет бизнес-требования к автоматизации (БТА) со слов заказчика (если, конечно, заказчик может логично и детально их сформулировать, что на практике оказывается тоже проблематичным). Далее на основе полученного БТА аналитик составляет техническое задание (ТЗ) под разработку для программиста: другими словами, переводит бизнес-требования на язык программирования в виде алгоритмов и графических интерфейсов, учитывая, безусловно, технические условия работы будущего программного обеспечения как самостоятельного, так и в интеграции с уже существующими системами. 

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

Ну, и наконец, дело программиста (или группы программистов) - все реализовать и передать на тестирование заказчику и системному аналитику. По результатам внести необходимые коррективы и завершить автоматизацию, то есть передать в эксплуатацию.

Все было бы хорошо, если считать, что заказчик:
  1. умеет строить бизнес-процессы (если проект вообще с нуля, и процесса как такового еще нет) или уже является обладателем работающего и формализованного бизнес-процесса;
  2. понимает работу системного аналитика и может квалифицировано сформулировать бизнес-требования в рамках системы, а не только краткосрочных задач;
  3. видит все причины и следствия своего процесса, понимать все условия и ограничения процесса, взаимодействия между участниками процесса;
  4. понимает и знает, как можно оптимизировать процесс: где можно реализовать с помощью автоматизации, а где нет - представлять четко себе цель автоматизации, представлять себе конечный результат автоматизации и понимать, как ее достичь;
  5. понимает принципы и основы работы программиста: понимать как описание преобразуется в ТЗ, чтобы быть вполне уверенным, что ваши требования дошли до программиста в нужном виде, а также в случае чего скорректировать работу программиста.
В моем случае, ни один из пунктов не выполнен. Такое бывает. В этом случае помогает решить задачу автоматизации специалист, заменяющий собой заказчика. Он взаимодействует и с заказчиком, и с аналитиком, и с программистом. Он отвечает за конечный результат проекта - является руководителем проекта, организует работу всей проектной группы.

Какими же навыками и знаниями, на мой взгляд, обладает данный специалист?

  • В области системотехники и формальной логики - необходимо для написание бизнес-процесса любой деятельности, так как необходимо "видеть" систему целиком со всеми ее взаимосвязями, логическими входами и выходами, чтобы не было "оборванных концов". Проблема в написании бизнес-процессов неумение определения границ процесса и его подпроцессов, неправильное акцентрирование на частном, но не общем, целом.
  • Знания принципов алгоритмизации - необходимо для написания бизнес-процесса в виде стройной и логической схемы с учетом всех условий и ограничений. Умение разрабатывать алгоритмы на нескольких уровнях глубины процесса.
  •  Знание основ алгоритмических языков программирования. Это дает возможность не только понимать, как словесное описание бизнес-требований перевести в техническое задание, но и мыслить уже в рамках автоматизации, а не только "желаний и пожеланий". Эти знания помогают взаимодействовать с программистом, говорить на его языке.
  •  Если говорить о реализации проекта в целом, то не помешает знать как организовать работу проектной группы, как управлять временным ресурсом (планирование работы) - здесь я использую сетевое планирование, как управлять выделенными ресурсами (это, если ресурсы берутся у других подразделений, а такое часто бывает), как контролировать работу и получать результат.
  •  Знание принципов процессного управления. Как не крути, а автоматизировать можно только уже формализованный процесс. Поэтому важно понимать в целом данную методологию.

У меня получился, собственно, портрет специалиста-системотехника. Большая часть знаний получено мною в вузовском образовании. Это фундаментальные знания. Обучить заказчика в короткий срок - час-два - практически невозможно, если он, скажем из сферы HR. Но я попробую :).

Собственно, этот пост родился в результате моих размышлений на эту тему - как научить заказчика понимать сложный процесс автоматизации, чтобы и он мог "говорить на этом языке". В одном я убедилась довольно быстро, что не зная основ, нельзя понять всего остального. Надо с их и начинать. Пытаться объяснить сложные вещи без "азбуки" на метафорах и примерах бесполезно. Правда, есть надежда, что если объяснить, что нужно знать и уметь для работы с автоматизацией, заказчик таки решится довериться и просто ждать, ориентируясь на выставленные сроки...

среда, 23 октября 2013 г.

Автоматизация процесса, это не только работа с аналитиком и программистом...

Но и политика и интриги внутри компании. Сложно автоматизировать чужой процесс извне, где отношения "заказчик-субподрядчик", когда не знаешь "внутренней кухни" и особенностей организации, ее ограничений, заморочек, правил безопасности и прочее. Сложно, когда заказчик в большинстве случаев не в коей мере не владеет процессной методологией, не знает собственных процессов и не представляет полную картину. Правда, в этом случае, нанимается специальный человек (или группа специалистов), которому и доверяется обязанность написания или разбора деятельности организации. Специалист пользуется доверием заказчика, его уважением, ну и оплатой за работу, стараются предоставить все необходимые данные, выполнить требования и прислушиваются к авторитетным его советам.

Как же усложняется задача, когда автоматизация происходит внутренними силами. Когда, даже если есть компетентные люди, способные прописать, разработать, проанализировать процесс, формализовать его таким образом, чтобы было понятно системным аналитикам, кто впоследствии пишет технические задания для программистов. И эта группа людей, в принципе, может автоматизировать все, за что не возьмется, так как знает внутренности организации, ее потребности, ограничения, правила безопасности и т.п. НО! Как правило у этих людей есть руководители, которые, к сожалению, не владеют (как заказчики) процессной методологией, не способны увидеть картину в целом и, хуже того имеют ежесекундные и противоречивые потребности, которые невозможно удовлетворить без построения целостной системы.

Вместо того, чтобы не навязывать и не требовать невозможного (например, продукт автоматизации, результат работы создаваемой или даже еще проектируемой в зародыше системы тут же, сразу: "Вот вам ткань, покажите мне сразу шапку, чтобы можно было ее потрогать и повертеть! И не важно, что ткань еще даже не раскроили."). Хуже того, требуют больше встреч, больше слов и нелепых требований, которые вместо продвигать процесс окончательно его стопорят. Самое страшное, как тут поспоришь? Ведь это непосредственные руководители! Они, конечно, специалисты в своей сфере (например, управление персоналом), но ни разу не аналитики, ни системотехники и ни программисты! Но уверены, что написать программу или алгоритм легко и просто - что-там буковки, циферки - садись и пиши, или рисуй.

Резюмирую. Успех автоматизации во многом зависит не только от занятых специалистов по автоматизации, но и во взаимоотношениях с внутренним заказчиком. Если он подчиняется правилам методологии разработки, все хорошо. Если нет - скорее всего ничего не получится. Если только не найдется лидер, способный "перепрыгнуть" через руководителя и достучаться до руководства компании и вопреки всему таки автоматизировать процесс.

Какие то грустные мысли занимают меня в последние дни. Хорошо только, что в моем случае надежда пока есть и разработка по ТЗ уже началась. Нужно только продержаться...