Эффективность работы любой организации (банка, промышленного предприятия, торговой компании) в значительной степени определяется эффективностью управления, его соответствием внутренним и внешним условиям деятельности организации. Изменение этих условий не может не вызывать и изменения способов управления. В последние десятилетия XX века традиционный функциональный подход к управлению начал вытесняться процессно-ориентированным подходом. Он идет по всему миру во всех отраслях, включая банковскую. Но, похоже, этот переход почти не наблюдается в российской банковской сфере. Почему? Может быть, российские банки еще не «созрели» для процессно-ориентированного управления? Или дело в инструментарии, точнее — в его отсутствии? Для начала уясним разницу между функциональным и процессным подходами к управлению.

Итак, при функциональном подходе к управлению перед каждой структурной единицей (сотрудник, отдел, управление) закреплен ряд функций, описана область ответственности, сформулированы критерии успешной и неуспешной деятельности. Как правило, горизонтальные связи между структурными единицами слабы, а вертикальные связи по линии « начальник-подчиненный » — сильны. Подчиненный отвечает только за порученные ему функции и, возможно, за деятельность своего подразделения в целом. Функции и результаты работы параллельных структурных единиц его не очень интересуют.

При процессном подходе к управлению каждая структурная единица обеспечивает выполнение конкретных бизнес-процессов, в которых она участвует. Обязанности, область ответственности, критерии успешной деятельности для каждой структурной единицы сформулированы и имеют смысл лишь в контексте конкретного бизнес-процесса. Горизонтальные связи между структурными единицами при таком подходе значительно сильнее, чем в случае функционального подхода. Вертикальные связи между структурными единицами и по линии « начальник-подчиненный » несколько слабее.

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

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

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

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

Нарастание динамики и конкуренции — характерные черты российского рынка банковских услуг. За последние семь лет он претерпел следующие изменения:

• вектор привлекательности банковских инструментов кардинально поменял свое направление, как минимум, три раза (ГКО, реальный сектор экономики, retail);
• банковский продукт по характеру потребления превратился из индивидуального в массовый;
• рост конкуренции на рынке банковских услуг заставил современный банк серьезно отнестись к управлению, инновациям и поиску новых банковских инструментов.

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

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

Такие тенденции не могли не отразиться на требованиях, предъявляемых к управлению банком и, прежде всего, к управлению банковскими продуктами, а также к АБС как инструменту управления банком.

Некоторые из них могут быть вполне удовлетворены в рамках функционального подхода к управлению.

Некоторые, но не все. Например, обеспечение своевременной и адекватной поддержки частым изменениям существующих и разработке множества новых банковских инструментов и продуктов. Функциональный подход к управлению (и поддерживающие его современные АБС) в этих условиях становится неадекватным. Нельзя же каждый раз создавать новое подразделение (или временную рабочую группу) под новый продукт или группу продуктов…

Итак, изменения на российском рынке банковских услуг объективно подталкивают российские банки к переходу на процессно-ориентированное управление.

Психологические и организационные трудности перехода на новую схему управления понятны и очевидны. Инструментальная поддержка (в наше время это поддержка со стороны ИТ) процессно-ориентированного управления — вещь менее очевидная и более сложная.

Функциональный подход к организации управления существует давно и его реализация даже в наше время вполне возможна без применения современных ИТ.

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

Информационная среда, создаваемая на основе системы класса workflow, оптимизирована для автоматизации управления бизнес-процессами. Основная задача при этом — обеспечить учет, контроль, анализ и планирование бизнес-процесса. Для этого она формулирует задания конкретным исполнителям, предоставляет необходимые инструменты и информацию для выполнения задания, обрабатывает полученный результат, контролирует срок исполнения задания.

Идеологи workflow из Workflow Management Coalition полагают, что без workflow процессно-ориентированная структура управления на практике не жизнеспособна.

Для перехода к процессно-ориентированному управлению предприятие должно описать бизнес-процессы «как есть» и «как должно быть». Затем, чтобы эти описания не остались стопкой документов, а послужили основой реорганизации управления предприятием, необходимы механизмы, побуждающие сотрудников и подразделения принять и провести реорганизацию. Одним из таких механизмов (со стороны ИТ) и является система класса workflow.

В результате перехода на процессно-ориентированное управление должно быть повышено качество бизнес-процессов и управления ими, в целом поднята на новый уровень эффективность основного бизнеса организации. А для ИТ-инфраструктуры организации основными результатами внедрения технологии workflow будут:

• отделение логики функциональных приложений от правил для бизнес-процессов;
• увязка функциональных приложений со стадиями бизнес-процессов;
• улучшение взаимодействия между технологом ИТ и бизнес-аналитиком (или банковским технологом).

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

В некоторых простых случаях, например, при переходе от последовательного согласования на кредит к параллельному, оказывается, что и не нужно создавать нового функционала бизнес-процессов, вполне достаточно существующего, который, возможно, надо просто перераспределить между бизнес-процессами (это возможно благодаря отделению логики функциональных приложений от правил для бизнес-процессов). Итак, для успешного перехода на процессно-ориентированное управление после этапа описания бизнес-процессов необходим этап работ по внедрению среды workflow. Для начала же на уровне пилотного проекта надо внедрить в жизнь несколько формализованных (по технологии workflow) бизнес-процессов «как есть», доказав тем самым, что эта среда жизнеспособна и готова поддерживать процессно-ориентированное управление для предприятия в целом.

Внедрение передовых методов управления и информационных технологий идет в России c некоторой задержкой в сравнении с западными странами.

Поэтому имеет смысл ознакомиться с опытом тех, кто идет первыми. Применение процессно-ориентированного управления на основе среды workflow в западных банках растет, но стоит отметить, что workflow очень широко используется и вне контекста поддержки процессно-ориентированного управления для поддержки отдельных бизнес-процессов банка с целью повышения их эффективности. Такой подход у нас получил название «кусочная автоматизация». Наиболее известные примеры применения workflow в западных банках — это, как правило, поддержка крупномасштабных бизнес-процессов, до которых российские банки еще не «доросли» (с этими примерами можно ознакомиться на странице http://www. e-workflow .org/case_studies/financial/index.htm).

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

Поэтому приведем очень простой гипотетический пример применения процессно-ориентированного управления в банке.

Отдел маркетинга банка совместно с банковскими технологами и финансовыми аналитиками разработал новый банковский кредитный продукт. Требуется провести ряд организационных мер по его внедрению.

Реакция подразделений и сотрудников: изменения в работе кредитного отдела, скорее всего, будут восприняты сотрудниками этого отдела положительно — внедрение нового продукта принесет дополнительную прибыль от деятельности их отдела. Остальные же подразделения, участвующие в его реализации (бухгалтерия, отдел отчетности, операционный отдел и др.), понесут лишь «расходы» в виде исполнения ранее не свойственных дополнительных функций. Особенно это снизит мотивацию сотрудников «профитных» подразделений.

При процессно-ориентированной структуре все задействованные участники бизнес-процесса внесут свой четко определенный вклад в поддержку нового банковского продукта. Подразделения не только положительно отнесутся к новому, более эффективному продукту, но и, будучи заинтересованными в конечном результате, быстро осуществят «практическую» регулировку бизнес-процесса: исправят технологические ошибки, внесут изменения, направленные на оптимизацию процесса.

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

Банки могут воспользоваться преимуществами процессно-ориентированного управления на основе среды workflow только в том случае, если эта среда будет средой и для основных функциональных банковских систем, т.е. она будет встроена в АБС. Точнее, сама АБС будет построена на принципах workflow.

Руководство компании Кворум, исходя из этих тенденций в сфере управления и изменений на российском рынке банковских услуг, а также из анализа развития современных информационных технологий, приняло решение о разработке АБС NEXT — банковской системы нового поколения класса workflow.

На момент выхода этой системы на российский рынок, который запланирован на апрель 2004 года, она будет содержать следующие функциональные блоки:

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

Основное назначение этой системы — создание и поддержка в банке процессно-ориентированной структуры управления, которая дает руководству банка надежный управленческий механизм для реального контроля над технологическими процессами в банке. Для перехода к процессному управлению АБС NEXT и предоставляет среду, которая будет обеспечивать исполнение формализованных бизнес-процессов, т.е. среду workflow.

В комплект поставки АБС NEXT также будет включен набор типовых моделей бизнес-продуктов.

Технологи банка могут не только описать и настроить выполнение бизнес-процессов, но и создать свой полностью новый банковский продукт, используя эти типовые модели.

Вторая основная черта АБС NEXT — это решение проблемы интеграции АБС с другими информационными системами, используемыми банками. Реально во всех банках используются разнообразные прикладные системы, и для ИТ-подразделений — обеспечение совместной работы этих систем является одной из основных задач. Часто эта задача является «головной болью» для ИТ-подразделений банков.

Хочется отметить, что проблема интеграции в АБС NEXT решена на качественно более высоком уровне, чем в существующих АБС благодаря разработке специальной Платформы NEXT, которая является частью АБС. Платформа создана на основе продуктов корпораций Oracle и IBM. Она позволяет использовать различные способы интеграции функциональных приложений, разработанных, как ИТ-подразделением банка, так и сторонними разработчиками.

Идея такого подхода, как говорится, «витала в воздухе». Аналогичный подход к созданию современной АБС предлагал эксперт Ассоциации российских банков (АРБ) Александр Лысенко (см. статью «Контуры современной архитектуры банковской автоматизации» в журнале «Банки и технологии», №3/2000, стр. 4-

9): «…Звездообразная архитектура, где центром звезды является не базовое приложение типа „Операционный день“, а приложение типа „Клей“. Все бизнес-приложения, включая даже основное, базовое, являются равноправными — каждое делает свою часть обработки и на равных взаимодействует с другими.

…Взаимодействие приложение — основная цель автоматизации…».

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

Изменения бизнес-процессов, как правило, не могут не затронуть кода функциональных приложений, поэтому проблема управления кодом приложений, его изменениями, при создании АБС NEXT была осознана как отдельная задача. АБС NEXT может развиваться не только ее разработчиками, но и специалистами банка. При установке новой версии системы от фирмы Кворум обеспечивается либо автоматическое, либо полуавтоматическое слияние ее с приложениями системы, модифицированными специалистами банка.

И последнее, по счету, но не по значению: десять лет назад, когда только зарождалась российская отрасль разработки ПО для банков, не хватало практического опыта создания банковских систем. Сейчас АБС NEXT разрабатывает профессиональная команда, имеющая практический опыт создания банковских систем и хорошо знающая как сильные, так и слабые стороны большинства решений, представленных в настоящее время на российском рынке.

Время процессно-ориентированного управления в российских банках пришло!

Благодаря изменениям на рынке банковских услуг, о которых мы говорили выше, российские банки «созрели» для перехода на процессно-ориентированное управление.

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

Переход банка на процессно-ориентированное управление вполне может происходить эволюционно, с максимальным сохранением уже сделанных вложений в управленческие технологии и ИТ-инфраструктуру. Собственно, именно так и переходят западные банки, которые постепенно переводят на новую схему управления те направления своей деятельности, прежде всего появляющиеся, которые в максимальной степени выигрывают от процессно-ориентированного управления. Российские банки, естественно, также могут идти таким путем, но в то же время специфика их деятельности дает основания для рассмотрения более радикальных, быстрых вариантов перехода к процессно-ориентированному управлению.

Необходимость применения процессно-ориентированного управления в последние годы все более явственно осознается банковским сообществом России. Об этом говорит и интерес, проявляемый специалистами банков к таким событиям, как конференции « Процесс-Банкъ », тема процессно-ориентированного управления все чаще рассматривается на различных отраслевых мероприятиях, в этом отношении выделяется последний Форум банковских разработчиков, прошедший в сентябре 2003 года.

Более того, многие отечественные банки уже начали работать над улучшением своих бизнес-процессов в рамках концепции процессно-ориентированного управления. Они повышают эффективность своей работы; без увеличения штата предлагают новые услуги, сокращают время обслуживания клиентов, снижают издержки. А использование формализованных процессов позволяет сократить время разработки новых продуктов. Причем эти результаты получены без полной инструментальной поддержки со стороны ИТ.

Но это только начало, в рамках которого осваиваются основные идеи и методологии, такие как методика сбалансированных показателей (Balanced Scorecard, BS), при наличии ясно сформулированной стратегии развития банка для управления можно эффективно использовать систему ключевых показателей результативности (Key Performance Indicator, KPI) и т.д. Применение BS, KPI и других методик на первом же этапе желательно, но не обязательно. Даже рационализация, «спрямление» бизнес-процессов на основе здравого смысла уже дает эффект.

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

1. Workflow Management Coalition является некоммерческой организацией, которая ставит своей целью расширение возможностей использования технологий workflow путем разработки единой терминологии и стандартов.

Функциона́льное программи́рование - раздел дискретной математики и парадигма программирования , в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании).

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

Функциональное программирование предполагает обходиться вычислением результатов функций от исходных данных и результатов других функций, и не предполагает явного хранения состояния программы. Соответственно, не предполагает оно и изменяемость этого состояния (в отличие от императивного , где одной из базовых концепций является переменная , хранящая своё значение и позволяющая менять его по мере выполнения алгоритма).

На практике отличие математической функции от понятия «функции» в императивном программировании заключается в том, что императивные функции могут опираться не только на аргументы, но и на состояние внешних по отношению к функции переменных, а также иметь побочные эффекты и менять состояние внешних переменных. Таким образом, в императивном программировании при вызове одной и той же функции с одинаковыми параметрами, но на разных этапах выполнения алгоритма, можно получить разные данные на выходе из-за влияния на функцию состояния переменных. А в функциональном языке при вызове функции с одними и теми же аргументами мы всегда получим одинаковый результат: выходные данные зависят только от входных. Это позволяет средам выполнения программ на функциональных языках кешировать результаты функций и вызывать их в порядке, не определяемом алгоритмом и распараллеливать их без каких-либо дополнительных действий со стороны программиста (что обеспечивают функции без побочных эффектов - чистые функции ).

Языки функционального программирования [ | ]

Ещё не полностью функциональные изначальные версии и Лиспа , и APL внесли особый вклад в создание и развитие функционального программирования. Более поздние версии Lisp, такие как Scheme , а также различные варианты APL поддерживали все свойства и концепции функционального языка .

Как правило, интерес к функциональным языкам программирования, особенно чисто функциональным, был скорее научный, нежели коммерческий. Однако, такие примечательные языки как Erlang , OCaml , Haskell , Scheme (после 1986) а также специфические (статистика), Wolfram (символьная математика), и (финансовый анализ), и XSLT (XML) находили применение в индустрии коммерческого программирования. Такие широко распространённые декларативные языки как SQL и Lex /Yacc содержат некоторые элементы функционального программирования, например, они остерегаются использовать переменные. Языки работы с электронными таблицами также можно рассматривать как функциональные, потому что в ячейках электронных таблиц задаётся массив функций, как правило зависящих лишь от других ячеек, а при желании смоделировать переменные приходится прибегать к возможностям императивного языка макросов.

История [ | ]

Первым функциональным языком был Лисп , созданный Джоном Маккарти в период его работы в в конце пятидесятых и реализованный, первоначально, для IBM 700/7000 (англ.) русск. . В Лиспе впервые введено множество понятий функционального языка, хотя при этом в языке применяется не только парадигма функционального программирования . Дальнейшим развитием Лиспа стали такие языки как Scheme и Dylan .

Концепции [ | ]

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

Функции высших порядков [ | ]

Функции высших порядков - это такие функции, которые могут принимать в качестве аргументов и возвращать другие функции. Математики такую функцию чаще называют оператором , например, оператор взятия производной или оператор интегрирования.

Функции высших порядков позволяют использовать карринг - преобразование функции от пары аргументов в функцию, берущую свои аргументы по одному. Это преобразование получило своё название в честь Х. Карри .

Чистые функции [ | ]

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

• Если результат чистой функции не используется, её вызов может быть удалён без вреда для других выражений.
• Результат вызова чистой функции может быть мемоизирован , то есть сохранён в таблице значений вместе с аргументами вызова. Если в дальнейшем функция вызывается с этими же аргументами, её результат может быть взят прямо из таблицы, не вычисляясь (иногда это называется принципом прозрачности ссылок). Мемоизация , ценой небольшого расхода памяти, позволяет существенно увеличить производительность и уменьшить порядок роста некоторых рекурсивных алгоритмов.
• Если нет никакой зависимости по данным между двумя чистыми функциями, то порядок их вычисления можно поменять или распараллелить (говоря иначе вычисление чистых функций удовлетворяет принципам thread-safe)
• Если весь язык не допускает побочных эффектов, то можно использовать любую политику вычисления. Это предоставляет свободу компилятору комбинировать и реорганизовывать вычисление выражений в программе (например, исключить древовидные структуры).

Хотя большинство компиляторов императивных языков программирования распознают чистые функции и удаляют общие подвыражения для вызовов чистых функций, они не могут делать это всегда для предварительно скомпилированных библиотек, которые, как правило, не предоставляют эту информацию. Некоторые компиляторы, такие как gcc , в целях оптимизации предоставляют программисту ключевые слова для обозначения чистых функций . Fortran 95 позволяет обозначать функции как «pure» (чистые) .

Рекурсия [ | ]

Рекурсивные функции можно обобщить с помощью функций высших порядков, используя, например, катаморфизм и анаморфизм (или «свертка» и «развертка»). Функции такого рода играют роль такого понятия как цикл в императивных языках программирования. [ ]

Подход к вычислению аргументов [ | ]

Функциональные языки можно классифицировать по тому, как обрабатываются аргументы функции в процессе её вычисления. Технически различие заключается в денотационной семантике выражения. К примеру, при строгом подходе к вычислению выражения

print (len ([ 2 + 1 , 3 * 2 , 1 / 0 , 5 - 4 ]))

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

Как правило, нестрогий подход реализуется в виде редукции графа. Нестрогое вычисление используется по умолчанию в нескольких чисто функциональных языках, в том числе Miranda , Clean и Haskell . [ ]

В нефункциональных языках [ | ]

Принципиально нет препятствий для написания программ в функциональном стиле на языках, которые традиционно не считаются функциональными, точно так же, как программы в объектно-ориентированном стиле можно писать на структурных языках. Некоторые императивные языки поддерживают типичные для функциональных языков конструкции, такие как функции высшего порядка и списковые включения (list comprehensions), что облегчает использование функционального стиля в этих языках, в частности, такой подход широко применяется в практике языка Python . Другим примером является язык Ruby , который имеет возможность создания как анонимных функций с использованием связанных переменных (λ-объектов), так и возможность организации анонимных функций высшего порядка через блок с помощью конструкции yield . В языке Си указатели на функцию в качестве типов аргументов могут быть использованы для создания функций высшего порядка. Функции высшего порядка и отложенная списковая структура реализованы в библиотеках С++ . В языке версии 3.0 и выше можно использовать λ-функции для написания программы в функциональном стиле.

Стили программирования [ | ]

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

# императивный стиль target = # создать пустой список for item in source_list : # для каждого элемента исходного списка trans1 = G (item ) # применить функцию G() trans2 = F (trans1 ) # применить функцию F() target . append (trans2 ) # добавить преобразованный элемент в список

Функциональная версия выглядит по-другому:

# функциональный стиль # языки ФП часто имеют встроенную функцию compose() compose2 = lambda A , B : lambda x : A (B (x )) target = map (compose2 (F , G ), source_list )

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

Более точно, существует четыре ступени развития функционального стиля, в порядке убывания роли данных в программах:

• Рефал (для этой категории, представленной единственным языком, нет общепринятого названия);
• Аппликативные (Лисп , , Tcl , Rebol);
• Комбинаторные (APL / / , / );
• Бесточечные (чистые конкатенативные) (Joy , Cat , Factor , подмножество PostScript).

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

Особенности [ | ]

Основной особенностью функционального программирования, определяющей как преимущества, так и недостатки данной парадигмы, является то, что в ней реализуется модель вычислений без состояний . Если императивная программа на любом этапе исполнения имеет состояние, то есть совокупность значений всех переменных, и производит побочные эффекты, то чисто функциональная программа ни целиком, ни частями состояния не имеет и побочных эффектов не производит. То, что в императивных языках делается путём присваивания значений переменным, в функциональных достигается путём передачи выражений в параметры функций. Непосредственным следствием становится то, что чисто функциональная программа не может изменять уже имеющиеся у неё данные, а может лишь порождать новые путём копирования и/или расширения старых. Следствием того же является отказ от циклов в пользу рекурсии.

Сильные стороны [ | ]

Повышение надёжности а [ | ]

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

Удобство организации модульного тестирования [ | ]

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

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

Возможности оптимизации при компиляции [ | ]

Традиционно упоминаемой положительной особенностью функционального программирования является то, что оно позволяет описывать программу в так называемом «декларативном» виде, когда жесткая последовательность выполнения многих операций, необходимых для вычисления результата, в явном виде не задаётся, а формируется автоматически в процессе вычисления функций. Это обстоятельство, а также отсутствие состояний даёт возможность применять к функциональным программам достаточно сложные методы автоматической оптимизации.

Возможности параллелизма [ | ]

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

Недостатки [ | ]

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

Для преодоления недостатков функциональных программ уже первые языки функционального программирования включали не только чисто функциональные средства, но и механизмы императивного программирования (присваивание, цикл, «неявный PROGN» были уже в Лиспе). Использование таких средств позволяет решить некоторые практические проблемы, но означает отход от идей (и преимуществ) функционального программирования и написание императивных программ на функциональных языках. В чистых функциональных языках эти проблемы решаются другими средствами, например, в языке Haskell ввод-вывод реализован при помощи монад - нетривиальной концепции, позаимствованной из теории категорий.

См. также [ | ]

Примечания [ | ]

1. А. Филд, П. Харрисон Функциональное программирование: Пер. с англ. - М.: Мир, 1993. - 637 с, ил. ISBN 5-03-001870-0 . Стр. 120 [Глава 6: Математические основы: λ-исчисление].

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

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

Рассмотрим следующий вариант — проектный подход к управлению . Как понятно из названия, этот вариант подходит для каких-то индивидуальных задач, исполнение которых требует привлечение специалистов самого разного профиля (кросс-функциональная команда), один из которых и назначается руководителем проекта, т.е. лицом, ответственным за его своевременное исполнение. Также (при необходимости) назначается главный инженер проекта. Логично предположить, что участники проектной команды попадают под "двойное" управление: со стороны назначенного руководителя проекта и своего традиционного функционального руководителя, которого никто не отменял. Получается некая матричная организационная структура, возникающая из-за одновременного применения двух подходов к управлению. Исключением могут являться проектные организации, для которых индивидуальные задачи — самое обычное дело, однако и здесь, несмотря на "стабильный" функционал главных инженеров и руководителей проектов, общий подход к системе управления не меняется.

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

Для процессного подхода к управлению характерно наличие пяти подсистем, на каждой из которых мы сейчас и акцентируем внимание.

Выделенный бизнес-процесс — сам объект управления с определением границ системы, т.е. "проблема", требующая решения. Сюда входят не только потребляемые ресурсы и результаты, которые необходимо получить, но и подсистемы (отделы), без прямого участия которых решения задачи не получится, а также внешнее окружение. В качестве примера можно привести кондитерское производство для ресторана (особенно если продукция реализуется розничным покупателям, а не только клиентам заведения) или отделение поддержки "1С" для компании, занимающейся ИТ-аутсорсингом широкого профиля. Соответственно, если "границы" будут заданы слишком "узко", то решение проблем будет невозможно в рамках выделенного Бизнес-процесса, а если слишком "широко", то придется разбираться с массой попутных задач, к которым наш Бизнес-процесс не имеет никакого отношения.

KPI (ключевые показатели эффективности) — инструменты управления любыми Бизнес-процессами, которые можно условно разделить на два типа: показатели производительности (результативности) и эффективности. Первые измеряют умение создавать качественный результат для потребителя в срок и в необходимом количестве, т.е. "делать правильные вещи". А второй — достигать результата, оптимально расходуя ресурсы, т.е. "делать вещи правильно". Совершенно естественно, что Результативность и Эффективность противоречат друг другу, поэтому необходимо использовать какую-то "золотую середину", получая достаточное качество в обмен на разумное количество затраченных ресурсов. При этом для любого Бизнес-процесса можно определить критерии совершенно не вдаваясь в подробности самого процесса, достаточно зафиксировать границы процесса и получить общее представление о нем, чтобы решить "что" и "как" измеряем. А вот с целевым значением пресловутой "золотой середины" все значительно сложнее, т.к. необходимо досконально изучить Бизнес-процесс, включая уровень автоматизации, квалификацию исполнителей, технологии и последовательность работ и т.д., чтобы понять, какое значение будет оптимальным для системы.

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

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

Регламент Бизнес-процесса — это четвертая подсистема, документ, который отвечает на такие вопросы как:

• какова цель деятельности Бизнес-процесса?
• где находятся границы процесса: начало и конец, участники, а также расположение именно этого процесса в схеме всех используемых процессов системы?
• каковы границы применения данного Регламента?
• кто Владелец Бизнес-процесса?
• какие KPI планируется использовать для планирования и контроля?
• насколько подробно описан Бизнес-процесс (необходим подробный документ)?
• каков порядок внесения изменений в настоящий Регламент?

Система мотивации — это пятая и последняя подсистема, основная задача которой понятна из названия: мотивировать участников процесса достигать целевые значения KPI, причем показатели мотивации могут быть выбраны не только из KPI Бизнес-процесс, для которого внедряется процессный подход, но и для более широкого Бизнес-процесса. Самый простой пример — "Подбор персонала". Вакансия появилась, кандидатов рассмотрели, выбранный вышел на работу. Казалось бы, результат получен, поэтому Результативность выполнена. Однако, если расширить границы до "Подбор и адаптация персонала", то Результативность можно оценивать по факту прохождения адаптации в коллективе и ее успешности (качества), а не просто по факту "закрытия" вакансии. Вот только для этого потребуется не только качественная система мониторинга, но и проведение анализа причин отклонений, чтобы произвести действительно качественную коррекцию.

Обратите внимание на тот факт, что разработка и внедрение процессного подхода к управлению — задача непростая и весьма трудоемкая, поэтому мы рекомендуем использовать его только для наиболее проблемных Бизнес-процессов, не забывая соотнести ожидаемый результат с себестоимостью внедрения данного подхода. Кроме того, в процессе описания и анализа "проблемного" Бизнес-процесса Вы организуете обмен информацией между участниками, практически "мозговой штурм", что приведет к единству в понимании Бизнес-процесса. А это, в свою очередь, позволит решить солидную часть проблем системного и поведенческого характера, поэтому даже если Вы внедрите не все подсистемы Бизнес-процесса, Результативность и Эффективность системы управления серьезно возрастут. А ведь именно для этого его и внедряют, не так ли?

Функция - это целенаправленная деятельность, способ поведе­ния элементов в активной системе. Результаты действия каждого эле­мента в системе суммируются и приводят к целесообразному резуль­тату в целом. Соответствие этому общему результирующему воздей­ствию данного элемента и есть его соответствие системе, целому. По­этому «функцию в системном ее понимании можно определить как такое отношение части к целому, при котором само существование или какой-либо вид проявления части обеспечивает существование или какую-либо форму проявления целого» (Сетров М. И. Основы функциональной теории организации. - Л., 1972. - С. 31).

Как видно, функция характеризует активную, кибернетическую систему. Активная система - система организованной природы (растение, животное, человек, человеко-машинные, технико-технологические объекты и др.), обладающая целесообразно упорядоченной структурой и достигающая в процессе функционирования какой-то цели.

Функциональный подход ориентирует исследователя на выявле­ние особенностей, законов и закономерностей функционирования систем, абстрагируясь от их субстратно-структурной основы. К нача­лу формирования функционального подхода можно отнести исполь­зование метода чисто функционального исследования под термином «черного ящика». «Черный ящик» - это системы, структура и внут­ренние процессы которых неизвестны или очень сложны. Отвлекаясь от содержания «черного ящика», акцентируют внимание на задаче обнаружения функциональных зависимостей между входными и вы­ходными параметрами системы в процессе ввода на вход заранее за­данных воздействий (сигналов).

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

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

во-вторых, проблемы передачи информации; проблемы управле­ния; комплекса проблем, решаемых в рамках теории автоматов; задачи построения моделей принятия решений, проблемы оптимизaции функционирования систем и др. (см., например: Кочергин А. Н. Научное познание: формы, методы, подходы. - М., 1991).

В процессе становления функциональный подход установил и выделил ряд принципов на которые он опирается при анализе специ­фики активных систем. К таким концептуальным средствам относят­ся: принцип единства объекта и среды; принцип функциональной замкнутости, включая принцип обратной связи; принцип иерархично­сти систем; принцип целевого управления и др. (см.: Марков Ю. Г, Функциональный подход в современном научном познании. - Новосибирск, 1982).

Функциональный подход, функционализм, функциональный анализ наиболее развиты в самых организованных - социальных системах и подсистемах.

Функциональный подход в социологии - один из основных методологических подходов в современном обществоведении. Его сущность состоит в выделении элементов социального взаимодействия подлежащих исследованию, и определении их места и значения (функции) в некоторой связи, качественная определенность которой делает необходимым ее системное рассмотрение. Функциональный подход ориентирует исследователя на выяснение функций одних об­щественных явлений по отношению к другим в рамках данного об­щества. Так, детально анализируются функции государства, права, искусства, идеологии и т.д., а также базиса и надстройки; экономиче­ских, социальных, политических отношений; социально­-экономических, политических и культурных институтов и т.п. Иссле­дуя эти функциональные отношения, ученые стремятся уяснить соци­альные механизмы и способы их воспроизводства, повторяемости, самоподдержания.

Функциональный подход в техносфере широко развертывается и конкретизируется в теории и методологии научно-технического твор­чества. Его логика и методология хорошо просматриваются в поня­тийном аппарате: техническая функция, функциональный элемент, формулировка функций, функциональное строение технических сис­тем, функциональная структура, потоковая функциональная структу­ра, функциональная модель объекта, закон соответствия между функ­цией и структурой, функциональные критерии технических систем, функциональный анализ, функционально оправданные затраты, функционально-стоимостный анализ, законы и закономерности тех­нических систем и др. (см.: Техническое творчество: теория, методо­логия, практика. Энциклопедический словарь-справочник. - М., 1995).

Функциональное управление

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

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

Достоинства ФП:

Начальник всегда прав => быстрая реакция на указания выполнение

«Установил и пользуйся» - быстрый запуск организации в работу

«Твори и пробуй» - поощрение креатива

Ясно выраженная ответственность => для продвижения по карьерной лестнице достаточно эмоционального фактора

BPM- управление бизнес-процессами это моделирования, выполнения, управления и оптимизации бизнес-процессов.

Задачи BPM:

Получение знаний по отлаживанию и документированию различных видов организаций

Знание по идентификации и классификации

Установление характеристик качества бизнес процессов

Модифицированию прежнего менеджмента

Создание информационной поддержки для принятия обосновоных решений, в деятельности компании.

1. Понятие «организации». Виды организаций, их различия Процессный подход к управлению организацией. Понятие бизнес-модели. Особенности процессно-ориентированной организации.

Организация - социально техническое экономическая система, группа людей стремящееся к достижение общих целей

Функционирование – совместная деятельность

Организация состоит:

Неформальные

Формальные (право юридического лица)

Неформальная организация - спонтанно возникающая группа людей, достаточно регулярно вступающих во взаимодействие друг с другом.

Формальные:

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

Формальные организации подразделяются на коммерческие и некоммерческие организации.

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

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

Процессный подход к управлению

Управление процесс информативного взаимодействия субъекта управления (СУ) и объекта управления (ОУ), побуждающий совершить некоторое действие на достижение целей субъекта

Схема управления:

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

Процессный подход рассматривает управление как не прерывную серию взаимосвязяных управленческих функций:

Планирование действий

Организация действий

Мотивация действий

Координация действий

Контроль действий

А также дополнительные связующие процессы: коммуникация и принятие решений.

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

Условия непрерывности – возможность организации замены оборудования и сотрудников без создания критической ситуации.

Бизнес-модель - компактное упрощённое представление о бизнесе, предназначенное для целостного представления и анализа деятельности всей системы взаимосвязанных бизнес-процессов бизнеса

Особенности процессно-ориентированной организации:

Наличие бизнес моделей.

Организованная система управления информации

Разработка чётко установленного порядка в разработке ведении документации.

Организация имеет иерархию уровней управлений

Уровень стратегического управления (принятие решений с перспективой на 3-5 лет)

Уровень управлению эффективности производится (1-1,5 лет)

Операционная деятельность. -Операционное управление (планирование в рамках календарного месяца) -Оперативное управление (текущего месяца)

Управление реального времени (то что сейчас)

Дает возможность определить показатели и критерии оценки результативности, управления на каждом этапе управленческой цепочки.

Что дает процессная ориентация:

Сокращение времени выполнения процессов за счет регламентации и автоматизации

Увеличение качества выпускаемой продукции или оказания услуг

Введено управление на основе показателей

Гибкость, (готовность к переменам содруников)