1. Вводная

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

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

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

Читать далее »

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

Цели и задачи описания бизнес-процессов

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

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

Читать далее »

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

Наверное, не будет слишком уж сильным невежеством утверждать, что максимально возможный эффект для бизнеса от ИТ-решения, отнесенный к стоимости его разработки/внедрения — величина примерно одинаковая для решений разных вендоров, технологий, парадигм и т.п. Есть лишь только одна маленькая деталь – реальный эффект от ИТ-решения, как правило, существенно меньше максимального (часто иногда он меньше нуля) и стремится к максимальному в том случае, если это правильное решение для конкретной компании и внедряется оно правильными людьми. Попытки внедрить 1С в компаниях, где нужен SAP приводят к печальным последствиям. Равно как и внедрение SAP в компаниях, где вполне подойдет 1С приводит к неадекватным расходам на внедрение и дальнейшее сопровождение и, в конечном счете, к тем же печальным последствиям (для ИТ-руководства). Ну, собственно, это философия ИТ.

Читать далее »

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

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

Читать далее »

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

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

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

Читать далее »

Вероятностные методы принятия решений

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

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

Это похоже на игру между двумя участниками, рассмотренную в предыдущем разделе. Однако в данном случае вторым участником выступает не человек, а природа (судьба, проведение и т.п.).

Читать далее »

Линейное программирование

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

Для примера рассмотрим простую задачу, которую решим графически.

Пусть перед компанией А стоит задача организовать рекламную компанию, длительностью один месяц, на которую выделено в бюджете 10.000$. Имеется возможность разместить рекламный ролик на радио (стоимость минуты эфирно времени на радио 500$) и/или на телевидении (стоимость минуты на местном TV равна 1000$). Имеются статические данные об эффективности маркетинговых каналов. Так 1 минута на телевидении в среднем обеспечивает рекламодателю 15 новых клиентов, а 1 минута на радио – 10 новых клиентов. Кроме того, все рекламодатели должны соблюдать местное антимонопольное законодательство, в рамках которого общая длительность транслированных по всем каналам рекламных роликов не должна превышать 15 минут в месяц.

Вопрос: каким образом максимально эффективно (по количеству новых клиентов) с учетом бюджетного и законодательного ограничения распределить рекламную кампанию между радио и ТВ?

Читать далее »

Каждый человек ежедневно принимает десятки, сотни и тысячи решений. Стоит ли вставать с кровати? Что приготовить на завтрак? Поехать на машине или на метро? Что надеть? И т.д. и т.п. Несомненно, именно принятые нами ранее решения по большей части определили то, какие мы есть сегодня: насколько успешны, счастливы, богаты. Кроме того, многие из нас принимают решения, оказывающие влияние и на других людей: нашу семью, организацию, общество. Все это делает процесс принятия решений человеком, как минимум, интересным и достойным изучения, т.к. всем нам хочется принимать больше правильных решений и меньше неправильных.

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

Читать далее »

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

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

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

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

Читать далее »

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

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

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

Читать далее »