Практическая автоматизация. На примере лизинговой компании

Вступление.

Наткнулся на объявление о вакансии:

"В лизинговую компанию требуется бизнес-аналитик или менеджер по организационному развитию. Обязанности: обследование и анализ бизнес-процессов "as is", реинжениринг и приведение последних к формату "to be". Требования: опыт описания и формализации бизнес-процессов, знание нотаций описания бизнес процессов IDEF0, IDEF3, DFD (обязательно), или ARISeEPC, владение UML, владение BPWin или ARIS или IDEF0/EMTool, MSVisio, знание стандартов ISO, опыт внедрения систем менеджмента качества, участие в проектах по внедрению информационных систем."

Я не знаю точно, как они к этому пришли. Может быть нынешний бизнес-аналитик не оправдал надежд или софтверная фирма, взявшаяся автоматизировать деятельность этой компании, собиралась заниматься предварительным бизнес-анализом в течении полугода и за 60% стоимости контракта. Вот и пришла в голову идея о собственном аналитике - и денег сэкономим и за результат меньше волноваться надо. А может быть, взлетела компания, клиенты валом повалили, доходы уверенно вверх - да только стали не справляться с объемами. Документы теряются, счета выставляются не вовремя, а любую справку финансисты готовят по два дня - какой уж тут оперативный и качественный менеджмент - абсолютный хаос.

Нет, не знаю, как они к этому пришли. Знаю одно - люди ждут чуда - явление бизнес-аналитика народу. Придет аналитик со знанием и ARIS, и UML, и IDEF0, и обязательно DFD - поначертит диаграмм, и станет всем светлей. Правда, в этих DFD-диаграммах, составленных в строгом соответствии с нотациями Йордана, никто кроме этого аналитика вряд ли понимает … хотя, их IT-Директор тоже понимает, но он диаграммы DFD в нотациях Гейна-Сэрсона предпочитает. А ведь суть то в том, что все эти диаграммы должны быть согласованы и с простыми, и с "высокопоставленными" сотрудниками тоже. Вот придут, например, люди с этими картинками к Председателю Правления компании, покажут ему и скажет он им … Но это уже за рамками литературного языка.

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

От сохи и от печки.

С Excel начинали все. Вернее, с ним начинали, с ним и прожили бы, если не нужда. По договорам своя таблица, по кредитам - своя, платежи - в третьей, задолженности - в четвертой. Как хорошо! Вот только расчет Доходов и Расходов превращается в мучительную сборку ссылок на самые разные ячейки в множестве листов раздельных файлов. Только скомпонуешь - ра-а-а-з, опять ошибка "значение не определено" или "циклическая ссылка" - в это время "очередной" пользователь в своей табличке что-то подправил ему нужное. Или совсем смешной случай - на одном компьютере система при вводе числа 8 заменяла его на 13 (!). Как попало это "правило" в сервис Автозамены Excel никто не знает, только обнаружилось это не сразу. Понятно, к чему это привело.

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

Не удивлюсь, если от финансового директора скоро будут требовать опыта программирования в SCALA и администрирования DB2.

И вот появляется в коллективе новый человек, именуемый программистом, который задает свой коронный вопрос - "что делать?". Коллектив несет к нему свои таблицы и говорит: Вот, нам бы это, как его - автоматизировать бы".

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

Поэтому:

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

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

3. За состояние, правильность и полноту автоматизации каждого отдельного процесса программист и пользователь должны нести одинаковую ответственность и иметь одинаковую заинтересованность.

4. Определите последовательность автоматизации бизнес-процессов с точки зрения эффекта для бизнеса компании.

По науке.

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

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

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

Всё вроде бы сделано правильно и в строгом соответствии, так сказать. Выбор продукта, платформы или решения должен определяться необходимыми функционалами и требованиями к системе, а не наоборот - это аксиома. То есть - "правильной дорогой идете, товарищи". Но, как заметил один из директоров нашей компании - "готов голову поставить, но все участники конкурса ответят, что их система (решение) полностью удовлетворяет нашим требованиям и будут уверять, что оно для нас самое-самое". Самое смешное - мы (я имею в виду себя и коллег по "цеху") это и сами понимали. По крайней мере, уж "тяжелые" платформы, такие как BAAN, SAP R/3 мы не рассматривали "как кандидатов". Кстати, в печати упоминалось о том, что достаточно известная лизинговая компания приступила к внедрению автоматизированной системы управления деятельностью на базе … SAP R/3. О результатах внедрения не сообщалась. В рейтинге журнала Эксперт по результатам этого года та компания "благополучно" переместилась из второго десятка в конец списка может быть благодаря автоматизации - все силы и средства ушли на это.

… И через полтора месяца мы имели ровно столько предложений, сколько было направлено запросов.

По ту сторону баррикад.

Итак, по эту сторону мы - лизинговые компании, по другую они - IT-интеграторы, поставщики ПО и фирмы-разработчики. Там и там люди. Вот, например, наш начальник Управления анализа рисков - высшее финансовое и аттестат аудитора, знание методик оценки ФХД, бизнес-планов и кредитных рисков, опыт работы руководителем кредитного подразделении банка. Не астролога же брать - "Уважаемые члены кредитного комитета, звезды подсказывают мне, что этому клиенту можно верить в пределах установленных лимитов". Так и у них - руководитель проекта (высшее специальное, опыт руководство проектами, знание PMBOK, сертификат IPMI), бизнес-аналитик, архитектор информационной системы и т.д.

И работают они в соответствии с методиками и требованиями - теми же ARIS и UML, IDEF0 и DFD, а так же ERD и IDEFX или PMBOK и ГОСТ/ISO 22190.

И по-другому им нельзя.

Во-первых, если кто-то не владеет и не использует эти методики, то на работу в софтверную компанию он просто не попадет.

Во вторых, в случае неуспеха проекта чем он тогда обоснует неудачу перед своим руководством - "я всё выполнял в полном соответствии с методикой - это они не представили нужные материалы", или перед заказчиком - "что написано, то и сделано. Полностью. А где написано, что лизинговые платежи могут пересчитываться с учетом ранее сделанных фактических платежей? Нигде. Конечно, мы может это сделать, но за отдельные деньги. И поскольку, это потребует переработки ядра системы, то это займет …. дней, месяцев, лет"

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

Поэтому, когда вам приносят план работ, в котором первым пунктом стоит "Обследование бизнес-процессов предприятия (60%), то знайте - он составлен с использованием технологии ARIS, а если "Построение бизнес-моделей - (40 % общего времени, степень готовности 10-20%)" - перед вами технология RUP. И дальше всё будет проистекать по этим или смежным с ними методиками.

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

Так что, как говорилось в одной интермедии - "не-е, без белил нам нельзя".

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

Кстати о нотации (правильнее, средстве моделирования функциональных требований к системе) DFD, знание которой в приведенной в начале статьи вакансии "обязательно". Как пример, DFD (Data Flow Diagram) упоминается в примере использования методики для реорганизации переполненного клерками офиса, относящегося к 20-м годам: Осуществляющий реорганизацию консультант обозначил кружком каждого клерка, а стрелкой - документ, передаваемый между ними. Используя эту диаграмму, консультант предложил схему реорганизации, в соответствии с которой два клерка, обменивающихся множеством документов были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии друг от друга ….

Ну, клерков то мы рассадим правильно, а дальше?

Виртуозное владение методиками не означает успех дела. Человек, печатающий слепым методом со скоростью 250 знаков в минуту и свободно программирующий макросы в WinWord'е не обязательно талантливый писатель.

Но и обратное не верно.

Заключение.

Вспомню старый анекдот. "Собрание в колхозе. Колхоз - полный развал и повальное пьянство. Тема собрания - "Как нам улучшить жизнь". Выступает председатель колхоза: "Товарищи, мы тут посовещались и решили. У нас есть два плана - реальный и фантастический. С какого начать?" Колхозники: "Давай с реального!" Председатель: "Реальный план таков - дождаться, когда прилетят марсиане, они нам всё и сделают" - "А фантастический какой"?" - "Начать нормально работать".

Я не знаю ни одного стороннего бизнес-аналитика, который бы разбирался в лизинге на уровне "as is" (они есть, наверно, но их просто не знаю) и уж тем более на уровне "to be".

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

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

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

Автор.
01.2004 г.

На страницу Оглавления