tsegelnyk | Entries tagged with внедрение

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

И вот казалось бы - работа сделана, что еще нужно? Чего ждут от консультанта?
А я скажу.

Ждут консультаций. Ждут решений. Ждут инноваций. Ждут изменений.
( Read more... )

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

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

И даже если представить, что проект себя не оправдает, то и вина будет лежать исключительно на инициаторе. И беда, если этим инициатором было ИТ.

При внедрении любого программного продукта существует несколько подходов к предоставлению результата Заказчику. Под результатом я понимаю программу, настроенную или скорее всего настроенную по бизнес-требованиям.

Понятно, что Интегратор ничего сам не программирует. Понятно, что он сам, как правило, не создает базу данных с 0, не создает ее структуру. Он лишь обеспечивает адаптацию купленного Заказчиком продукта к его бизнес-требованиям, настраивает его. А теперь давайте представим картинку: Заказчик заказал, Интегратор знает программу как свои пять пальцев, вдоль и поперек, он занимается ее настройкой, чтобы она работала, как описал Заказчик в бизнес-требованиях. Настраивает ее, отдает Заказчику и,… казалось бы, все должны быть довольны, ан нет. Программа не работает! Кто касался программирования или внедрения, сразу понимает, что мы пропустили один шаг – тестирование. Тестирование того, что настроил Интегратор, и насколько это соответствует тому, что заказывал Заказчик.

( Read more... )

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

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

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

Был свидетелем забавного диалога.
Интегратор, далее И, Заказчик, далее З.

З: Как-то плохо у нас работает "поиск" в нашей новой, почти внедренной, программе..
И: Да, понимаете, это происходит потому, что поиск клиента происходит не по сущности, которая принадлежит сущности клиент. Поиск происходит по сущности сделка. потом необходимо сопоставить с клиентом и отобразить вам клиента.
З: и?
И: Ну как же. Вот поиск по "фамилии" нормально идет?
З: Ну, в целом, да, лучше.
И: Вооот, это потому что ищется в той же сущности.
З: Ну хорошо, но что делать? В БТ есть такое требование. Мы хотим идентифицировать клиента по номеру договора, по номеру его карты.
И: Ну-у-у, надо чтобы _ваш_ администратор базы посмотрел в чем проблема и сделал оптимизацию.
З: Ээээ, как это? Ведь мы покупаем решение, которое должно работать так как нужно, или хотя бы описано в БТ.
И: И что? Мы же _только_ интеграторы. Мы берем систему и _немножко_ оптимизируем под ваши требования. Мы же не меняем базу, а значит не можем нести за нее ответственность. Все вопросы к разработчику базы, т.е. к Oracle.
З: (непонимающе) Да как же это? Вы нам продали решение...
И: (раздраженно) Ну вот смотрите. Есть база данных, а есть программа (надстройка), которая строится на ней. И вот саму надстройку мы можем крутить, вертеть как угодно, а вот база - это не наше. Это все Oracle. Вот вы же официально являетесь пользователем Oracle, вот обращайтесь к ним, пишите запрос, мы вам поможем составить, и будем ждать ответа.
З: ...

В целом, проблему решили. Благо нашлись правильные слова, люди, которые решили объединить усилия для решения задачи Заказчика. Но сам диалог очень показателен. Показателен с точки зрения работы и общения с заказчиком ДО продажи, ДО начала внедрения и ПОСЛЕ - ближе к окончанию внедрения, к окончанию работ, подписанию актов выполненных работ.

Я считаю, искренне считаю, что Интегратор _должен_ решать проблемы и задачи Заказчика. Не просто внедрять программу, не просто внедрить и забыть, а выполнить _действительно_ то, что было обещано в периоде обработки клиента при продаже своего _решения_. Мне кажется, что задача Интегратора самостоятельно разобраться во всех нюансах, проблемах, которые могли появится во время внедрения. Честь и хвала заказчика, если он вмешается и поможет, но это не его обязанность, если это не указано напрямую в Договоре. Но рассчитывать нужно и правильно только на свои силы. А абстрагироваться от проблемы, уходить от ответа или прикрываться тем, что "это не наше" - признак слабости компании. Я за компании-интеграторы, которые ответственно подходят к внедрению РЕШЕНИЯ. Именно решения, потому что Заказчику как правило нужен _ожидаемый _результат_, а не печать в прессе: "Был успешно внедрен проект .... в таком-то банке ".

Сейчас, все чаще, почти всегда уж, Интеграторы говорят о том, что они внедряют _решения_, а не просто программы.

На деле же, после внедрения Заказчик остается один на один с внедренной _программой_, никак не решением.
Да, приятные исключения бывают.

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

Накатали ошибок на страничку.

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

Я лишь в который раз напоминаю себе и всем читающим, насколько важны эти Бизнес-требования, которые создаются в самом начале проекта, когда совершенно непонятно как ЭТО выглядит в системе, как оно вообще будет работать, но ЛОГИКА уже должна быть. Как говорится, must have.

Когда приходит интегратор, он говорит: "Мы решим ваши задачи. Мы автоматизируем ваши процессы. Мы изменим ваш процессы. Все будет зашибись".

Заказчик верит, он добрый, и у него есть деньги. Деньги свои он отдает интегратору за решение собственных задач и проблем. И что получает?

А получает очередную головную боль - программа с которой никто не умеет работать, постоянные "глюки", тормоза системы, отсутствие вменяемой документации, но при всем при этом интегратор с горящими глазами убеждает: "Это именно то, что вы заказывали. Подписывайте акты!". Какой бы не смешной казалась ситуация, но так происходит с большинством проектов в Украине.

Чтобы избежать такой ситуации нужно ОЧЕНЬ четко понимать какие ЗАДАЧИ, не абстрактные, должна решить внедренная программа. Еще раз скажу - ОЧЕНЬ ЧЕТКО, и это четко - надо изложить в бизнес требовании. Сами не умеете, не понимаете - приглашайте специалистов. Поверьте, выйдет дороже.

- существует ли вообще?

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

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

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

Что происходит дальше?

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

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

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

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

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

2. Разговаривайте с заказчиком не о "космосе", а о том, какую практическую пользу должна принести внедряемая система

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

4. Отталкивайтесь от мировых best-practices. Безусловно их нужно адаптировать для Украины.

5. Обязательно используйте свой опыт.