Самое начало проектирования IT-архитектуры на любом уровне всегда связано с бизнес-целями на том же уровне. Если проектируется архитектура некоторого IT-решения, то архитектору нужно прежде всего узнать, какова цель у этого решения. Если говорится о некоторой IT-системе, нужно узнать цели создания этой системы, причём не заявленные в техническом задании, а реальные, и это далеко не одно и то же. И даже на уровне архитектуры предприятия архитектору нужно руководствоваться бизнес-целями предприятия, знать их, отслеживать их изменения, быть готовому к резким изменениям этих целей.
Во времена моей юности происходило рождение первых прикладных программ. Появился MS Office, Photoshop и всё такое. Компьютер превращался из умного калькулятора с возможностью программирования под свои нужды в удобный персональный рабочий инструмент, позволяющий автоматизировать низкоуровневые бизнес-задачи.
Когда я был молодым специалистом, только что закончившим институт, появились первые распределённые системы. Теперь задачи стали решаться не только на персональном компьютере, но появилась возможность использовать мощности серверов, быстрого обмена данными в компьютерной сети, выросли возможности хранилищ данных.
Введение в управление бизнес-процессами
Эволюция привела информационные системы в облака, к искусственному интеллекту, большим данных, дополненной реальности. И бизнес-цели становились всё более высокими. Если сначала цель была упростить рутинные операции отдельного сотрудника, то теперь разговор идёт о бизнес-целях целых государств, отраслей, больших корпораций и социальных систем в масштабах планеты.
Вместе с целями росла и роль IT-архитектора. Точнее, на каждом бизнес-уровне требовался человек, который мог бы осознать потребности этого уровня в решении актуальных задач и предложить решения, опираясь на лучшие практики и оптимально подобранный стек технологий.
Вроде бы это не должно вызывать каких-то особых вопросов. Однако по моим наблюдениям, при разработке IT-решений очень часто допускается очень грубая ошибка, стоящая лишних затрат во всех смыслах. И ошибка эта заключается в том, что по каким-то невразумительным причинам работа над проектом начинается не с определения реальных бизнес-целей потребителя разрабатываемого решения, а с каких-то других активностей. Можно сколько угодно изучать контракт, техническое задание, пользовательские истории и тому подобные вещи. Но если вы упустили бизнес-цели, у вашей работы нет фундамента.
Ошибка, безусловно, связана с незрелостью руководителей IT-проектов, которые мыслят критериями бюджета, сроков и минимального качества. Они быстро догадываются, что работа с бизнес-целями — это максимизация качества системы, а это ведёт к росту трудозатрат, т.е. появляются риски срыва сроков и нарушения бюджета проекта.
Молодым РП не хватает мудрости, чтобы понять, что жизнь шире и могущественнее треугольника «сроки-бюджет-качество». Реальность не плоская, она имеет объём и развивается во времени. Именно стремление к качественному выполнению работы приводило к появлению действительно выдающихся команд и выводило в свет по-настоящему талантливых и успешных IT-специалистов. Ведь если человек любит свою работу, он делает её качественно. Если же он замыкается между сроками и бюджетом, то качество становится минимальным, и это приводит к разрушению команды, к выгоранию сотрудников, к деградации культуры разработки.
Как описывать и внедрять бизнес-процессы в компании?
При чём же тут архитектор? Но разве не архитектор должен предлагать самое оптимальное решение? Даже если РП заблудился в трёх соснах показателях, то не архитектору ли надо напомнить о тех вещах, которые ему необходимы для решения его профессиональной задачи? Ведь бизнес-цели — это фундамент архитектурного решения. Если они определены не верно, фундамент пойдёт трещинами, и вся система в какой-то момент обрушится.
Сейчас на моих глазах разрабатывается более двух десятков разных систем. Их разрабатывают далеко не безызвестные компании-разработчики. И примерно в половине случаев я вижу именно эту самую ошибку. Разработчик хочет заработать, а дальше трава не расти. И то, что это самым негативным образом сказывается на его же команде, похоже, не сильно заботит руководство разработчика.
Талантливые специалисты потихоньку создают свои старт-апы, накапливают силы, апробируют подходы. Пока они разобщены, мы имеем то, что имеем. Но они уже начинают находить пути на рынок. Например, в качестве субподрядчиков, обладая уникальными технологическими решениями и эффективно организованными командами.
В итоге уже видится на горизонте смена парадигмы, когда крупные, неповоротливые и жадные компании окажутся на обочине, а основные контракты начнут выполнять небольшие, но талантливые команды разработчиков, чьи результаты будут очень быстро становиться известными на рынке IT-услуг, и именно их рейтинг будет определяющим при привлечении их к контрактам.
Скажете, что это утопия? А вот и посмотрим. Лет через пять, если не будет каких-то глобальных катаклизмов, которые смогут полностью перебаламутить IT-отрасль.
Источник: m-i-kuznetsov.livejournal.com
20 преимуществ автоматизации бизнеса
Компания, которая решается на внедрение новой информационной системы, как правило понимает предстоящие финансовые затраты. Многие так же понимают, что придется потратить свое время, усилия руководства и ключевых сотрудников. Что предстоит большой объем работы, и стресс. Но какие преимущества дает автоматизация?
Если вы задумались над проектом автоматизации, некоторые преимущества вы для себя уже выявили. Но если вы еще не решились на проект, возможно наш список преимуществ поможет вам добавить аргументов на чашу весов «пора автоматизировать».
Эффекты от автоматизации отнесены в ту или иную группу условно. Если что-то помогает нам, например, меньше тратить, оно же дает нам возможность больше зарабатывать. Или если мы более оперативно можем вывести сотрудника на работу, скорее всего, он начнет быстрее приносить пользу компании.
Из этих примеров видно, что все эффекты связаны между собой, и классификация условная. Мы решили типизировать преимущества, в первую очередь, чтобы посмотреть на них с разных точек зрения. Возможно, прочитав эффекты из какого-то блока, вы сможете добавить собственные преимущества, и расширите список целей проекта.
Итак, перед вами 20 преимуществ автоматизации бизнеса. Видеоверсия статьи.
Источник: vc.ru
Каким образом ис способствует целям бизнеса
Недавний Игорь Олегович к.т.н, аудитор,
ИТ аналитик управляющий партнер ООО «Любара М»
Каждая компания на разных этапах своего развития сталкивается с необходимостью выбора системы управления предприятием. В этой статье, я предлагаю рассмотреть подход к выбору информационной системы предприятия, который базируется на зависимости от этапа развития компании, жизненного цикла и стиля управления.
На практике, при подборе системы управления, предприятие рассматривает возможность ее создания собственными силами, опираясь на внутренние наработки и компетенций сотрудников, собирает систему из набора готовых решений, каждое из которых решает отдельную задачу (управление складом, управление продажами, транспортом и т.п.), либо внедряет существующие на рынке комплексные системы управления (например, ERP).
Растущие и развивающиеся предприятия еще не раз возвратятся к вопросам: Нужно ли менять систему или в каком направлении совершенствовать существующую? Почему выбрать именно эту систему? Какие задачи должна решать эта система? Каких результатов мы ждем от внедрения новой системы?
При выборе автоматизированных систем управления консультанты, ИТ аналитики, как правило, опираются на функциональные признаки – периметр и объем требуемой функциональности.
Наиболее распространенная классификация автоматизированных систем управления предприятием основана на выделении набора функций и их группировка по функциональным сферам использования. Отсюда появились такие стандарты как ERP, MRP, BPM, WMS и т.д. В целом все они представляют набор функционала сгруппированный по определенным критериям.
В какой-то степени это удобно, поскольку терминология опирается на вполне понятные вещи, например, выписка счета клиенту, расчет заработной платы, хранение ТМЦ на складе и т.д. Все бы хорошо, но функций существует огромное количество. При этом на практике, выполнение многих одних и тех же функции в разных компаниях выстроено по-разному. И получается, что в этом огромном пространстве функциональных требований при выборе того или иного решения теряется удобство прикладного использования понятия «функция». И это, на первый взгляд, парадоксально, ведь изначально функция направлена на достижение той или иной цели и для чего-то предназначена и, казалось бы, поэтому предназначению легко можно выбирать… В чем может быть подвох? Ситуация схожа с анекдотом:
– Чем занимаешься?
– Футбол смотрю…
– И какой результат?
– Шесть бутылок пива…
Всегда ли мы получаем нужный результат, даже после успешного внедрения системы? И почему часто происходит так, что к ожидаемому результату компания не приходит, а все останавливается на внедрении, а иногда и еще раньше?
Компании в рамках своей деятельности осуществляют ряд действий во внутренней и внешней среде, которые в свою очередь, направлены на достижение долгосрочных и краткосрочных целей.
Под внутренней средой я понимаю контур компании, к которому относятся любые отношения, взаимодействия, бизнес-процессы направленные на обеспечение жизнедеятельность компании. Например, внутренние регламенты, система мотивации, корпоративная культура, ведение бухгалтерского и управленческого учета, планирование, контроль, производственные операции, кадровый учет.
Внешняя среда – это отношения, взаимодействия, бизнес-процессы, которые осуществляет компания с внешними контрагентами. Такие как, продажи, работа с поставщиками, отношения с клиентами и инвесторами. Все действия компании, которые осуществляются во внешней среде, имеют прямое влияние на деятельность во внутренней среде.
Таким образом, мы получаем четыре типа группировок действий совершаемых организацией. Присвоим каждой группе ключевое слово, которое обобщают и определяют целевую область совершаемых действий и являются группой бизнес-процессов.
1 – долгосрочные во внешней среде — Проекты (P)
2- краткосрочные во внешней среде — Клиенты (C)
3- краткосрочные во внутренней среде — Учет (включая регламентный, управленческий, оперативные системы) (A)
4- долгосрочные во внутренней среде — Эффективность (E)
Расположим действия, которые совершает организация в простых квадрантах: оценках краткосрочной и долгосрочной перспективы, и выполнения действия во внутренней и внешней среде (Рис. 1).
Рис. 1. Сегментация действий по времени и окружению (внутреннему и внешнему).
Если мы переформулируем эти группировки в терминах информационных систем, то получим следующую карту категорий информационных систем (ИС) в краткосрочной и долгосрочных перспективе, во внутреннем и внешнем окружении (рис. 2).
Рис. 2. Карта категорий информационных систем в краткосрочной и долгосрочных перспективах во внутреннем и внешнем окружении.
К группе программ управления клиентскими процессами относится CRM (Customer Relationship Management — управление отношениями с клиентами), а также система управления лояльностью.
К категории программ эффективности относятся системы класса ССП (система сбалансированных показателей) в парадигме оценки деятельности по четырем уровням: финансы, клиенты, производство и персонал. ССП является системой помогающей эффективно настроить процессы работы компании и внедрить на этой основе систему оценок и мотивации KPI (ключевые показатели эффективности).
Учетная группа, пожалуй, самая объемная, поскольку включает в себя и системы бухгалтерского, т.е. регламентного учета и систему управленческого учета, и системы производственного назначения, логистики и т.д. Часто организации используют информационные системы расположенные только в этом квадранте, при этом считая, что обладают полноценными комплексными системами управления.
Таким образом, мы получили простую классификацию информационных систем (ИС). Для удобства использования название закодируем по начальным буквам ключевых слов информационных систем КУПЭ (программы Клиентские, Учета, Проектные, Эффективности).
Полученная систематизация полезна для понимания уровней существующих ИС предлагаемых рынком и используемых инструментов в компании и их достаточности для дальнейшего развития и достижения поставленных целей.
Но еще более интересным и полезным этот подход оказывается при сопоставлении со стилем управления компанией и ее жизненным циклом.
На любую информационную систему в процессе проектирования, внедрения и штатной работы влияет менеджмент компании. Результаты будут зависеть от работы системы «ИС-Менеджер». Влияет ли стиль руководства на эффективность работы ИС в компании и как это связано со стадией развития?
1. «Конечная цель процесса управления — сделать организацию результативной и эффективной в ближайшей и долгосрочной перспективе — не больше и не меньше»
2. «Для успешного функционирования организации необходимо, чтобы внутри организации выполнялись четыре функции: производство результатов, администрирование, предпринимательство и интеграция. Для успешного выполнения каждой функции должны выполняться роли в принятии решений P,A,E,I»
Автор выделяет 4 роли (стиля) менеджмента, которые организация должна быть способна осуществлять для успешного управления:
- производство результатов – краткосрочная результативность;
- администрирование – краткосрочная эффективность;
- предпринимательство – долгосрочная результативность;
- интеграция – долгосрочная эффективность.
На графике это представляется следующим образом:
Рис. 3. Краткосрочная и долгосрочная эффективность и результативность. Матрица РАПИ (в английской аббревиатуре – PAEI)
3. Далее, приведем график развития организации Адизеса, который демонстрирует аналогию с живой системой растущей и стареющей (Рис. 4).
Рис. 4. Этапы жизненного цикла организации.
Выделяются следующие этапы жизненного цикла организации:
«Выхаживание» (Courtship), «Младенчество» (Infancy), «Детство» или «Давай-давай» (Go-go), «Юность» (Adolescence), «Расцвет» (Prime), «Стабилизация» или «Поздний расцвет» (Stabilization), «Аристократизм» (Aristocracy), «Ранняя бюрократизация» (Early bureaucracy), «Бюрократизация и смерть» (Bureaucracy and death).
На каждом из этапов стадии роста компания переживает кризис. Компания либо успешно минует его, либо ей грозит преждевременное прекращения деятельности, при этом акцентируется, что не в связи с изменение конъектуры рынка, а в связи с неправильно организованным менеджментом. Соответственно, лекарством от кризиса является правильно сформированная команда управленцев с соответствующими каждому этапу стилями менеджмента.
Теперь вернемся к нашей модели информационных систем КУПЭ. И проведем между двумя моделями взаимосвязь.
Во-первых, для этого введем понятие сложности бизнес-процессов в компании. Категории простоты-сложности, конечно, существуют в отношении бизнес-процессов. При этом здесь мы будем понимать уровень сложности как увеличивающийся объем взаимодействий, количества внутренних и внешних участников этих взаимодействий и количества целей или результатов, которые компании ставит перед собой.
Графически, связь уровня сложности бизнес-процессов компании в зависимости от времени можно проиллюстрировать графиком:
Рис. 5. Ступенчатый вид зависимости сложности бизнес-процесса от времени.
Данная зависимость представляет ступенчатый вид. Действительно, сложность бизнес-процессов в организации меняется не плавно, а через некоторое время, при определенном созревании в руководстве компании необходимости изменения существующих способов взаимодействия, необходимости определении новых или переопределении старых целей. Иначе говоря, это происходит при оценке фактора эффективности в той или иной сфере деятельности, т.е. при оценке снижения существующего уровня эффективности до критического уровня или возможной её потенциальной утери. Следующее, что мы сделаем, покажем зависимость категорий ИС и финансовых возможностей (в т.ч. и потенциальных) в зависимости от времени, при этом будем иметь ввиду зависимость увеличения сложности бизнес-процессов от времени, которая представлена на рис. 5.
На каждом этапе перед организацией стоят задачи, которые информационная система должна быть способна поддерживать. Каждый отрезок кривой развития – функционирование организации на определенном уровне сложности бизнес-процессов с доминированием той или иной группы бизнес-процессов: проектной, клиентской, учетной, эффективности (рис. 6).
Рис. 6. График этапов ИС развития
Анализируя графики ИС развития (Рис. 1) и этапов жизненного цикла организации (Рис. 4) мы видим, что существует очевидная связь между ними.
Рис. 7. График соответствия этапов развития компании по Адизесу этапам развития информационных систем и категории информационных систем.
Наблюдаемое соответствие опишем более подробно в таблице 1.
Таблица 1. Соответствие этапов развития компании по Адизесу этапам развития компании по кодам информационных систем КУПЭ.
Этап по Адизесу
и код менеджмента
Этап и код информационной системы
Источник: www.m-bo.ru
