Комментарии 10
Мистер У делает информационные системы, а пример из практики — купи-продайная фирмочка. Как организовать подобный рынок в ИТ-конторе — совершенно непонятно.
Может, имеет смысл написать отдельную публикацию про решение для IT-компании? Я спрошу у мистера У.
Не знаю, что именно вы понимаете под «IT-компания», но было бы очень интересно для компании, которая разрабтаывает, продает, внедряет и сопровождает софтверный продукт.
Спросите, если не затруднит, очень интересно. Как перенести концепцию внутреннего рынка на некоторые моменты уже сейчас понятно, но было бы очень интересно даже их почитать в «правильных формулировках», а по некоторым моментам так вообще не очень ясно в какую сторону двигаться.
Спросите, если не затруднит, очень интересно. Как перенести концепцию внутреннего рынка на некоторые моменты уже сейчас понятно, но было бы очень интересно даже их почитать в «правильных формулировках», а по некоторым моментам так вообще не очень ясно в какую сторону двигаться.
Отлично! Я поговорил с мистером У, и мы решили описать решение для IT-компании. Ваше уточнение — очень важное, потому что у нас как раз стоит вопрос с выбором кейса. У нас на примете есть компания, которая как раз делает то, о чем Вы написали: «разрабатывает, продает, внедряет и сопровождает софтверный продукт». Проблема в том, что у них (пока) только один клиент — крупный интернет-провайдер, для которого они написали биллинг и еще кое-что. Мы будем очень рады, если кто-нибудь поможет нам с более широкой/детальной постановкой задачи.
в каком виде нужна постановка?
Вот у нас есть продукт, который уже вполне можно назвать mature. Прикладная область — медицина.
1. не так-то просто с потенциальными покупателями разговаривать вообще, чаще всего они или не понимают что же им от автоматизация может дать совершенно (медики) или понимают в очень узких сегментах (приглашают админов на ранних стадиях)
но допустим, «продажа» состоялась
2. внедрение, в подавляющем большинстве случаем буквально ломает все текущие процессы заказчика
у нас кусочек медицины довольно узкий, и нам удалось отработать технологию внедрения так, что за пару-тройку недель, один инженер приносит людям счастье (для среднего масштаба клиента). Но наши коллеги, которые охватывают предприятие целиком, внедряют в лучшем случае пол года (с хорошей административной поддержкой заказчика и так далее).
подписали акты внедрения, заказчик уже понял, что ему реально становится лучше
3. сопровождение
каким-бы долгим или глубоким не было внедрение, всегда будут вопросы по ходу дела. Вроде как тоже, технологии ServiceDesk, HelpDesk, UserSupport и всякие такие отработаны, но довольно часто есть «трения». Например из недавнего, что слышал на курилке: заказчик пишет много запросов в ServiceDesk. По каждому запросу инженер поддержки реагирует, проверяет, уточняет, если что-то релаьно поправить — правит, и возвращает заказчику. В итоге висит пачка в «обратной связи», ожидающая подтверждения «да, спасибо, проблему решили» или «нет, мы всё еще страдаем».
Очевидно что в такой момент вопросы должны уходить в более высокие уровни, и они уходят, но там всё сразу становится размыто.
4. развитие продукта, в контексте сопровождения
Жизнь идет своим чередом, пишут новые законы, придумывают всякое новое, и продукт должен за всем этим успевать. Иначе молодые и дерзкие выкинут с рынка.
Опять-же, понятно, что нужно как-то искать баланс, что новое-модное тянуть в продукт, что не спешить, но снова, натыкаешься на всякие проблемы, когда фича, реализованная весной (sales стучали пяткой в грудь, что смогут с этой фичей лучше продавать, сапорт — дешевле сапортить итд), пол года ждет когда же она доберется до реальных заказчиков.
Подозреваю, что для любого не сильно массового продукта, проблематика будет примерно такой-же.
Даже сотни потребителей всё еще способны проявить индивидуальность, которую игнорировать слишком дорого. Значит как-то нужно управлять коллективом так, что бы бизнес-цели достигались как можно более эффективно, заказчики не уходили к конкурентам, продукт становился лучше и так далее.
Вот у нас есть продукт, который уже вполне можно назвать mature. Прикладная область — медицина.
1. не так-то просто с потенциальными покупателями разговаривать вообще, чаще всего они или не понимают что же им от автоматизация может дать совершенно (медики) или понимают в очень узких сегментах (приглашают админов на ранних стадиях)
но допустим, «продажа» состоялась
2. внедрение, в подавляющем большинстве случаем буквально ломает все текущие процессы заказчика
у нас кусочек медицины довольно узкий, и нам удалось отработать технологию внедрения так, что за пару-тройку недель, один инженер приносит людям счастье (для среднего масштаба клиента). Но наши коллеги, которые охватывают предприятие целиком, внедряют в лучшем случае пол года (с хорошей административной поддержкой заказчика и так далее).
подписали акты внедрения, заказчик уже понял, что ему реально становится лучше
3. сопровождение
каким-бы долгим или глубоким не было внедрение, всегда будут вопросы по ходу дела. Вроде как тоже, технологии ServiceDesk, HelpDesk, UserSupport и всякие такие отработаны, но довольно часто есть «трения». Например из недавнего, что слышал на курилке: заказчик пишет много запросов в ServiceDesk. По каждому запросу инженер поддержки реагирует, проверяет, уточняет, если что-то релаьно поправить — правит, и возвращает заказчику. В итоге висит пачка в «обратной связи», ожидающая подтверждения «да, спасибо, проблему решили» или «нет, мы всё еще страдаем».
Очевидно что в такой момент вопросы должны уходить в более высокие уровни, и они уходят, но там всё сразу становится размыто.
4. развитие продукта, в контексте сопровождения
Жизнь идет своим чередом, пишут новые законы, придумывают всякое новое, и продукт должен за всем этим успевать. Иначе молодые и дерзкие выкинут с рынка.
Опять-же, понятно, что нужно как-то искать баланс, что новое-модное тянуть в продукт, что не спешить, но снова, натыкаешься на всякие проблемы, когда фича, реализованная весной (sales стучали пяткой в грудь, что смогут с этой фичей лучше продавать, сапорт — дешевле сапортить итд), пол года ждет когда же она доберется до реальных заказчиков.
Подозреваю, что для любого не сильно массового продукта, проблематика будет примерно такой-же.
Даже сотни потребителей всё еще способны проявить индивидуальность, которую игнорировать слишком дорого. Значит как-то нужно управлять коллективом так, что бы бизнес-цели достигались как можно более эффективно, заказчики не уходили к конкурентам, продукт становился лучше и так далее.
НЛО прилетело и опубликовало эту надпись здесь
Очередную публикацию можете посмотреть тут: megamozg.ru/post/23764
Она, вроде бы, про IT-компанию, но не про разработчиков ПО.
Она, вроде бы, про IT-компанию, но не про разработчиков ПО.
Было бы интересно на примерах из этой статьи узнать те самые проценты, которые определяют заработки продажников и закупщиков.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как построить внутренний рынок в отдельно взятой фирме: теория и практика