Блог Александра Башкирова

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

Про видение “заказчик/продавец/исполнитель/пользователь”

Просмотров: 2567Комментарии: 0
IT Blogs

Тема стара как мир. И не о кризисе. Местами очень даже теоретическая.

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

  1. внутренняя формализация задачи - про этот этап вообще-то частенько забывают...
  2. определение, "делаем сами" или "покупаем нечто". (Предположим, что "покупаем" - так видится интереснее)
  3. мониторинг рынка и определение бюджета
  4. формирование внятного документа - приглашения на тендер (в нем, по хорошему, должны быть описаны основные моменты: зачем, что, ожидаемый результат и т.д.)
  5. рассмотрение предложений (поступают от продавца исполнителя)
  6. выбор
  7. договор
  8. внедрение (исполнитель)
  9. эксплуатация (пользователь)

П. 7 - 9 пока оставим вне рассмотрения, и перейдем к п.6 - "Рассмотрение предложений" и "Выбор". Проблема в том, что очень часто (статистика взята по 5..10 моим ИТ знакомым из разных сфер основного бизнеса) декларируемые возможности не соответствуют действительности, или соответствуют в некоторых специфических условиях. Решается все, как правило, административными мерами, доработками или патчем, что либо увеличивает бюджет внедрения, либо сроки, либо трудозатраты на баголовство.

Способов борьбы с этим явлением придумано на данный момент два:

  1. На этапе "Рассмотрение предложений" - "Выбор" попросить исполнителя реализовать самую заумную из имеющихся схем (бизнес-процессов) в тестовой системе, или заказчику проделать эту операцию самостоятельно (если исполнитель считает, что реализация его силами затруднена в силу трудозатратности операции, неинтересности или нежелания заниматься клиентом и/или задачей и т.д.)
  2. Составить договор так, что в случае, если что-то где-то пойдет не так, как задумывалось (декларировалось продавцом), то результатом подобного действия явилась бы солидная финансовая оплеуха исполнителю или разработчику системы (если система перепродается третьими лицами)

Как вариант, может "прокатить" комбинация этих двух способов.

Разумеется, продавец прктически любой системы постараться избегнуть подобных опытов "по живому": трудозатраты, да и не факт, что купят. С другой стороны,- продавать надо, поэтому на подобные вещи хоть неохотно, но идут. (Встречал ОДНУ компанию, которая САМА предложила реализовать процесс в системе. Нонсенс - но приятно видеть нормальный профессиональный подход).

А теперь, внимание. Вопрос к коллегам: а как вы решаете подобного рода коллизии? Интересно мнение как "исполнителей", так и "заказчиков".

PS. Очень надеюсь на ответ А.Тенцера, М.Елашкина, А.Куприянова, В.Брокуса, П.Попова и всех-всех-всех (да простят меня не упомянутые лично). :D

Кросспост из моего ИТшного блога на ITBlogs.ru

Оставьте комментарий!


Комментарий будет опубликован после проверки

     

  

(обязательно)