Изменения

Уважаемый (потенциальный?) пользователь системы "Курьерская служба 2008"MeaSoft!

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

==О системе==На сегодняшний день система «Курьерская служба» MeaSoft отметила своё четырнадцатилетние. За это время её положительно оценили и активно с нами сотрудничают более 300 компаний. Наши партнёры находятся в разных странах: Россия, Казахстан, Узбекистан, Таджикистан, Украина, Белоруссия, Киргизия, Латвия. С помощью нашего сервиса ежедневно 4,5 тысячи курьеров доставляют 60 тысяч отправлений от 11 тысяч клиентов.Сама созданная нами «Курьерская служба» MeaSoft состоит из 200 связанных друг с другом таблиц, в некоторых из которых встречается по 50 миллионов записей. Мы постоянно работаем над её совершенствованием, чтобы наши клиенты всегда были впереди конкурентов.

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

*'''Мелкие компании''' -  — стартапы и прочее, со штатом до 10 курьеров. Такие компании не очень интересно автоматизировать - автоматизировать — выигрыш производительности труда от ведения базы данных, штрих-кодирования, расчета зарплаты и ти т.д д. -  — минимальный, если вообще есть. Такие компании неплохо (если такое слово вообще применимо к подобным компаниям) себя чувствуют и в экселе, а учет отправлений сводится к фразе "ну «ну я тебе давал отправление, ты его доставил?"». Понятно, что для вменяемой автоматизации у такой компании нет ни денег ни потребности. Мы на такие компании никогда не нацеливались, и в свое время у нас получался неплохой симбиоз с системами вроде "Аурамы"«Аурамы», которая позволяла подобной компании начать работать "в «в один клик" клик» за 3 копейки. Это позволяло компании слегка подрасти, и при приближении к 10 сотрудникам их система переставала справляться, они переходили в следующую категорию и приходили к нам. "Конкуренты" "выращивали" «Конкуренты» «выращивали» нам клиентов! В последнее время ситуация изменилась: подобные системы стали дороже нашей, и клиенты из данной категории стали к нам приходить сразу. Надо, может, приподнять цены уже наконец? Подумаю.*'''Средние компании''' -  — со штатом курьеров от 10 до 200 курьеров. Это наша ниша рынка. Самая распространенная, созревшая к автоматизации. Здесь можно добиться действительно большого роста эффективности труда. В тоже время, как правило, компаниям из этой категории хватает функциональности нашей системы "из коробки"«из коробки», процесс внедрения прост и надежен. Хотелки по доработкам если и возникают, то уже в процессе работы, а не на старте, что сильно упрощает их реализацию.*'''Крупные компании''' -  — более 200 курьеров. Данная ниша гораздо меньше предыдущих, компании как правило уже чем-то автоматизированы, что создает много проблем при внедрении: в "их" «их» системе что-то было реализовано по-другому, пользователям всегда не удобно переучиваться, они устраивают саботаж. Бизнес-процессы уже отлажены, и встроиться в них, повторить, нужно практически без репетиции. Нужно вести длительные переговоры, совещания, анализировать бизнес-процессы, составлять ТЗ на доработки для тех участков, которые у них уже были как-то реализованы, дорабатывать без тестирования на продакшене, как мы любим. В общем, очень много непродуктивной деятельности. В проекте внедрения занято куча народа, всякого рода <rspoiler text="руководители направлений">Риторический вопрос: Сколько руководителей нужно привлечь к проекту, чтобы его провалить?</rspoiler> и даже "менеджеры «менеджеры самого среднего звена"звена». Вероятность успеха проекта внедрения граничит с авантюрой. Такие клиенты у нас тоже есть, в основном выросшие из 2-й категории. Не бросать же людей из-за того, что они выросли! Мы в ответе за тех, кого приручили ©.

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

Итак, наши клиенты из второй группы, со средним чеком в районе 20 т.р. в месяц, но их [http://courierexe.ru/our_clients.htm достаточно]. У нас нет <rspoiler text="якорного">Какое правильное слово кто-то придумал для обозначения того, что тянет вниз, не дает двигаться куда нужно!</rspoiler> клиента: поступления от самого крупного клиента не превышают 55 % всего бюджета. Это позволяет мне быть действительно не предвзятым и уверенным в надежности выстроенной структуры. Так же, очень важный момент: это позволяет мне не играть в политику, балансируя между "хочу" «хочу» отдельных клиентов и правильностью разработки с точки зрения системы, а ставить во главу угла именно архитектуру, гибкость, масштабируемость и поддерживаемость системы.

Бюджет, в основном, складывается из регулярных платежей наших клиентов: за аренду и поддержку. Продажа системы, равно как и платная доработка, в финансовом отношении мало эффективна, т.к. так как это разовые вещи, на которых построить надежный прогнозируемый бюджет невозможно. Подобные разовые платежи в сумме обеспечивают нам 10-1515 % бюджета, что, согласитесь, пренебрежимо мало. Поэтому мы ориентируемся на долгосрочное взаимовыгодное сотрудничество со всеми нашими клиентами. Мы заинтересованы в росте бизнеса всех наших клиентов, и способствуем этому всеми доступными нам способами.

===Эффективность===Моя главная задача - задача — эффективность использования всех ресурсов для получения максимальной отдачи для бизнеса наших клиентов на каждый потраченный рубль. Для этого я применяю все возможные подходы. У каждого из этих методов есть свои плюсы и минусы, поэтому я постараюсь их все здесь описать, чтобы Вы вы понимали, откуда берутся некоторые минусы в работе с нами, и что Вы вы получаете взамен.====Команда====Для эффективной работы команда должна быть компактной. Оптимальный размер команды для разработки ПО - 7-15 человек. Это тот объем, который позволяет руководителю дотянуться до каждого сотрудника, проконтролировать работу, объединить усилия всех сотрудников в единый организм и комплексно, целенаправленно решать стратегические задачи. Понятно, что написать Windows с такой командой невозможно, ее нужно сильно расширять. Однако это требует существенного расширения сопутствующего персонала. К сожалению, речь идет не только о найме проект-менеджера на каждую группу по 7 человек (зарплаты которых измеряются сотнями тысяч рублей), но и раздутии штата прочими сотрудниками, напрямую в процессе разработки/сопровождения не занятыми, поскольку работу групп нужно координировать, большую задачу нужно разбить на блоки, требования, функциональность, методы тестирования, интерфейсы взаимодействия которых нужно полностью задокументировать. Объем технической документации при "правильном" подходе занимает больше времени и стоит дороже, чем сам процесс разработки. После разработки каждого куска его надо тестировать отдельными штатными единицами, а потом пытаться склеить эти блоки вместе. В случае же с компактной командой ее можно просто собрать вместе, и сказать: "Давайте сделаем вот это. Ты делаешь это, а ты - вон то, через 2 дня собираемся вместе и проверяем". Поэтому я стараюсь удержать размер команды в оптимальном диапазоне. Пусть мы не можем такими силами взяться за какие-то глобальные мегапроекты, зато предельно эффективно решаем конкретные текущие задачи, которые ставят перед нами наши клиенты.

Мы==== Команда ====Для эффективной работы команда должна быть компактной. Оптимальный размер команды для разработки ПО — 7-15 человек. Это тот объем, конечнокоторый позволяет руководителю дотянуться до каждого сотрудника, разбираемся проконтролировать работу, объединить усилия всех сотрудников в предметной областиединый организм и комплексно, целенаправленно решать стратегические задачи. Я начинал свою карьеру с работы курьером еще в 2000-м годуПонятно, потом в офисе курьерской службы. Коммерческий директор - обязательно что написать Windows с опытом руководящей работы в курьерской службе. Мы лично встречаемсятакой командой невозможно, общаемся с клиентамиее нужно сильно расширять. Остальные сотрудники обязательно начинают свою работу с изучения предметной области. Полное погружение в нее - обязательное условие нормальной работы каждого сотрудникаОднако это требует существенного расширения сопутствующего персонала. К сожалению, большинство разработчиков подходят к своей работе речь идет не только с позиции "мы умеем писать кодо найме проект-менеджера на каждую группу по 7 человек (зарплаты которых измеряются сотнями тысяч рублей), но и раздутии штата прочими сотрудниками, напрямую в процессе разработки/сопровождения не занятыми, поскольку работу групп нужно координировать, нам заказчик скажетбольшую задачу нужно разбить на блоки, что написатьтребования, мы сделаем". Лично сталкивался с "автоматизаторами"функциональность, которые только от меня узнавалиметоды тестирования, что после распределения заказов по курьерам их интерфейсы взаимодействия которых нужно еще физически на складе сортироватьполностью задокументировать. Объем технической документации при «правильном» подходе занимает больше времени и стоит дороже, чем сам процесс разработки. После разработки каждого куска его надо тестировать отдельными штатными единицами, а не потом пытаться склеить эти блоки вместе. В случае же с компактной командой ее можно просто скинуть курьерам полученные спискисобрать вместе, и сказать: «Давайте сделаем вот это. Ты делаешь это, а ты — вон то, через 2 дня собираемся вместе и проверяем». Поэтому я стараюсь удержать размер команды в оптимальном диапазоне. Пусть мы прикладываем все усилия к томуне можем такими силами взяться за какие-то глобальные мегапроекты, зато предельно эффективно решаем конкретные текущие задачи, чтобы такими не бытькоторые ставят перед нами наши клиенты.

====Задачи====Для максимизации эффективности труда необходимо выполнять только самые эффективные задачи. Есть такое <rspoiler text="правило 20 и 80 процентов">20% людей выпивают 80% пива. 20% работы приносит 80% пользы.</rspoiler>. КонечноМы, мы не делаем только 20% работыконечно, но делаем 90%разбираемся в предметной области. Как мы выбираем наиболее востребованные задачи, чтобы не работать впустую? *Мы никогда не придумываем сами себе задачи. У нас есть много клиентов, которые "на местах" сталкиваются Я начинал свою карьеру с живыми ситуациями, и передают нам свои пожелания. Зачем нам изобретать свой велосипед?*К нам постоянно поступает множество "хотелок" от клиентов. Им нужно какработы курьером еще в 2000-то выдавать приоритеты. Для этого я их делю на 2 категории. Первая категория содержит:**То, что просят многие.**То, без чего реально процесс у клиента не работает.**Том году, что можно сделать быстро и без <rspoiler text="хвостов.">Бывает, что задача вроде быстрая и простая, но когда ее сделаешь, клиент начинает уточнять: "а нам надо не так, а сделайте вот так", и мы вязнем потом в переговорах, уточнениях того, что же ему на самом деле нужно, многократных переделкахофисе курьерской службы. А время идет и другие, серьезные задачи стоят. Такую задачу нужно поставить Коммерческий директор — обязательно с опытом руководящей работы в очередь, запланировать на нее время чтобы все согласовать, утрясти и реализовать по четко поставленному ТЗкурьерской службе.</rspoiler>**ТоМы лично встречаемся, что входит в поддержку пользователейобщаемся с клиентами.**То, за что <rspoiler text="платятОстальные сотрудники обязательно начинают свою работу с изучения предметной области.">Плата за доработку, как я буду писать ниже, не столько заработок, сколько демонстрация заинтересованности клиента Полное погружение в доработке. Так же, оплата нее — обязательное условие нормальной работы предполагает установку конкретных сроков, которых мы должны придерживатьсякаждого сотрудника. Впрочем, что касается сроковК сожалению, то выбирая между сделать наспех но большинство разработчиков подходят к сроку, или завалить срок но сделать качественно я всегда выбираю второе.</rspoiler>Вторая категория - все остальное:**То, что просит своей работе только один клиентс позиции «мы умеем писать код, и ему это не критично, он не считает это важным чтобы сделать платно.**Тонам заказчик скажет, что <rspoiler text="очень объемное">Месяц работы программистанаписать, напримермы сделаем».</rspoiler>Лично сталкивался с «автоматизаторами», а польза не очевидна.**Токоторые только от меня узнавали, что <rspoiler text="не понятно, как делать.">Понятно, что было бы удобно, если бы программа сама доставляла отправления, или печатала после распределения заказов по курьерам их нужно еще физически на принтере зарплаты курьеровскладе сортировать, но как это сделать мы ПОКА а не знаемпросто скинуть курьерам полученные списки. Может придумаем в будущем?</rspoiler>Естественно, сначала Поэтому мы делаем задачи из первой категории, и по остаточному принципу - остальные (даже если в теме обращения написано "ОЧЕНЬ ВАЖНО!!!"). Такой подход приводит прикладываем все усилия к тому, что некоторые задачи могут стоять в очереди вечно. Но их процент чтобы такими не очень большой, а сделать все и сразу попасть в светлое будущее, конечно, невозможнобыть.

====Экстремальное программированиеЗадачи ====В своей работе в разной степени мы используем принципы [https://ruДля максимизации эффективности труда необходимо выполнять только самые эффективные задачи. Есть такое <rspoiler text="правило 20 и 80 процентов">20 % людей выпивают 80 % пива.wikipedia20 % работы приносит 80 % пользы.org</wiki/Экстремальное_программирование экстремального программирования]rspoiler>. Конечно, мы не делаем только 20 % работы, но делаем 90 %. Мое самое любимое положение из него - код должен максимально быстро начинать приносить реальную пользу (прибыль!) нашим клиентамКак мы выбираем наиболее востребованные задачи, чтобы не работать впустую?* Мы никогда не придумываем сами себе задачи. При классическом подходе к разработкеУ нас есть много клиентов, которые «на местах» сталкиваются с живыми ситуациями, и передают нам свои пожелания. Зачем нам изобретать свой велосипед?* К нам постоянно поступает множество «хотелок» от клиентов. Им нужно как -то выдавать приоритеты. Для этого я уже писал, сначала пишется документация всей доработки, потом разбивается их делю на подзадачи2 категории. Первая категория содержит:** То, реализуетсячто просят многие.** То, тестируетсябез чего реально процесс у клиента не работает.** То, отлаживается что можно сделать быстро и т.дбез <rspoiler text="хвостов.">Бывает, на все это уходит куча времени что задача вроде быстрая и денег. Потом простая, но когда ее пытаются сдать заказчикусделаешь, и тут оказывается, что задачу изначально клиент начинает уточнять: «а нам надо не совсем так поняли. Чтобы этого всего избежать, мы сходу пишем небольшие кускиа сделайте вот так», и сразумы вязнем в переговорах, даже без тестированияуточнениях того, отдаем заказчику. Дачто же ему на самом деле нужно, при этом могут быть ошибкимногократных переделках. Но заказчик сразу начинает пользоватьсяА время идет и другие, решать свои бизнес-серьезные задачи, тстоят.е. экономить деньги. Ошибки, замечания, пожелания, которые он обнаруживает уже Такую задачу нужно поставить в промышленной эксплуатацииочередь, а не запланировать на примере [https://ruнее время чтобы все согласовать, утрясти и реализовать по четко поставленному ТЗ.wikipedia.org</wiki/Научный_юмор#Сферический_конь_в_вакууме сферических коней в вакууме], как это делает тестировщикrspoiler>** То, что входит в реальном времени передаются разработчикам и так же быстро устраняютсяподдержку пользователей. В результате мы получаем огромный прирост эффективности - в разы** То, если не на порядкиза что <rspoiler text="платят. С одной стороны сильно сокращаются издержки на документирование">Плата за доработку, тестированиекак я буду писать ниже, случаи решения несуществующих задачне столько заработок, а с другой стороны - клиент получает самую свежую функциональность со скоростью горячих пирожков и сразу начинает на этом зарабатыватьсколько демонстрация заинтересованности клиента в доработке. Пусть эта функциональность и не обязательно полная или надежная - это лучшеТак же, оплата работы предполагает установку конкретных сроков, чем ничегокоторых мы должны придерживаться. Иногда задача даже может остаться не очень доделанной - главноеВпрочем, что она решает поставленную перед ней конкретную задачу на конкретных данныхкасается сроков, то выбирая между сделать наспех но к сроку, или завалить срок но сделать качественно я всегда выбираю второе. Поэтому иногда бывает</rspoiler>Вторая категория — все остальное:** То, что просит только один клиент пытается воспользоваться функцией, а она и ему это не работаеткритично, тон не считает это важным чтобы сделать платно.к. писалась для конкретной задачи. С точки зрения клиента это ** То, что <rspoiler text="глюкочень объемное">- Исправьте немедленно!!!Месяц работы программиста, например.</rspoiler>, а с нашей - это недофича, которой могло и польза не бытьочевидна.** То, и что <rspoiler text="никто бы не узналпонятно, что она могла бытькак делать.">ЕслиПонятно, что было бы удобно, конечноесли бы программа сама доставляла отправления, или печатала на принтере зарплаты курьеров, она но как это сделать мы ПОКА не заявлена знаем. Может придумаем в перечне функциональности системы: в этом случае мы должны обеспечить корректность ее работы в соответствии с документацией и/или здравым смысломбудущем?</rspoiler>Естественно, сначала мы делаем задачи из первой категории, и по остаточному принципу — остальные (даже если в теме обращения написано «ОЧЕНЬ ВАЖНО!!!»). Такой подход приводит к тому, что некоторые задачи могут стоять в очереди вечно. Но их процент не очень большой, а сделать все и сразу попасть в светлое будущее, конечно, невозможно.

==== Экстремальное программирование ====В своей работе в разной степени мы используем принципы [https://ru.wikipedia.org/wiki/Экстремальное_программирование экстремального программирования]. Мое самое любимое положение из него — код должен максимально быстро начинать приносить реальную пользу (прибыль!) нашим клиентам. При классическом подходе к разработке, как я уже писал, сначала пишется документация всей доработки, потом разбивается на подзадачи, реализуется, тестируется, отлаживается и т. д., на все это уходит куча времени и денег. Потом ее пытаются сдать заказчику, и тут оказывается, что задачу изначально не совсем так поняли. Чтобы этого всего избежать, мы сходу пишем небольшие куски, и сразу, даже без тестирования, отдаем заказчику. Да, при этом могут быть ошибки. Но заказчик сразу начинает пользоваться, решать свои бизнес-задачи, то есть экономить деньги. Ошибки, замечания, пожелания, которые он обнаруживает уже в промышленной эксплуатации, а не на примере [https://ru.wikipedia.org/wiki/Научный_юмор#Сферический_конь_в_вакууме сферических коней в вакууме], как это делает тестировщик, в реальном времени передаются разработчикам и так же быстро устраняются. В результате мы получаем огромный прирост эффективности — в разы, если не на порядки. С одной стороны сильно сокращаются издержки на документирование, тестирование, случаи решения несуществующих задач, а с другой стороны — клиент получает самую свежую функциональность со скоростью горячих пирожков и сразу начинает на этом зарабатывать. Пусть эта функциональность и не обязательно полная или надежная — это лучше, чем ничего. Иногда задача даже может остаться не очень доделанной — главное, что она решает поставленную перед ней конкретную задачу на конкретных данных. Поэтому иногда бывает, что клиент пытается воспользоваться функцией, а она не работает, так как писалась для конкретной задачи. С точки зрения клиента это <rspoiler text="глюк">- Исправьте немедленно!!!</rspoiler>, а с нашей — это недофича, которой могло и не быть, и <rspoiler text="никто бы не узнал, что она могла быть">Если, конечно, она не заявлена в перечне функциональности системы: в этом случае мы должны обеспечить корректность ее работы в соответствии с документацией и/или здравым смыслом</rspoiler>. ====Коммуникация====

====Бюрократия====

====Поддержка====Поддержка системы является крайне важным элементом ее совершенствования. Когда мы видим, что с каким-то вопросом к нам обращаются регулярно - регулярно — мы понимаем, что что-то там сделано не идеально, и это нужно исправлять.

====Эволюция====Наша компания, как и наша система, растет. Примерно на 3030 % в год. Есть плюсы:*Скорее всего мы не закроемся :-)*Система становится все более функциональной, и "из коробки" «из коробки» позволяет решать все больше задач.*Мы совершенствуем свои процессы, их надежность и эффективность постоянно повышаются. <spoiler text="Примеры">*Когда-то документы оформлялись вручную, и лицензионные ключи на аренду также делались вручную. Ключ после оплаты можно было ждать неделю, старожилы помнят.*Мы разработали и внедрили тикетную систему. Уже через несколько месяцев мы задавались вопросом "а «а как же мы работали до этого?"». Сейчас через нее проходят все обращения, задачи. Она позволяет нам не потерять ни одного вопроса или хотелки (хотя не скрою, некоторые вопросы у нас могут висеть и очень долго, т.к. так как решения их пока нет. Но все-равно мы о них помним!)*Недавно мы сделали интерактивное [https://home.courierexe.ru/whatsnew средство отслеживания изменений] в системе. Теперь в реальном времени можно смотреть, что сделали программисты, по каким тикетам, в каких блоках.</spoiler>

*Система становится все сложнее, и любая доработка в ней требует все больше усилий. Это общая беда больших систем: по подсчетам Microsoft программисты тратят 9090 % времени на поиск места в коде их ERP-систем, куда нужно внести изменение, и только 1010 % -  — на написание этих изменений.*Уменьшается объем личного присутствия. Несколько назад я лично приезжал к каждому клиенту в Москве, с ноутбуком, и что-то для них дописывал. Но это и хорошо: компания гораздо лучше работает, когда она выстроена как система, а не ручное управление одним человеком. ==Отказ от ответственности==

==Что входит в покупку (аренду) системы====Что входит в поддержку=====Тариф 1===

===Тариф 2=== 

* Регулярное обновление программы до последней версии — версии — 1 раз в месяц.* Настройка системы под бизнес-процессы клиента в рамках возможностей, доступных без перекомпиляции программы и ее модулей (за исключением настройки модуля интеграции с внешними системами для импорта/экспорта данных во внешние системы) —  — не более 5-ти рабочих часов разработчика в месяц. В большинстве случаев это создание дополнительных отчетов и печатных форм, настройка автоматизации. ===Тариф 3===

* Регулярное обновление программы до последней версии — версии — 1 раз в месяц.* Настройка системы, доработка функциональности, в том числе с перекомпиляцией программы и/или ее модулей — модулей — не более 15-ти рабочих часов разработчика в месяц.

==Оплата счетов== 

Мы добились минимальной стоимости системы за счет автоматизации многих процессов — процессов — в том числе и автоматизация рассылки ключей. Ключи рассылаются только после зачисления средств на наш расчетный счет.

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

*'''Обратиться "по адресу"«по адресу»''' Обратиться в поддержку можно по будням '''(а теперь и в выходные с 10 до 18!)''' (в соответствии с трудовым календарем Российской Федерации) с 8:00 до 21:00 по московскому времени любым удобным для Вас способом: Почта [mailto:support@courierexe.ru support@courierexe.ru], Телефон +7 (495) 987-17-12, бесплатный по России 8 (800) 707-90-35 или skype: courierexe, courierexe1, courierexe2, courierexe3, courierexe4.

*'''Представиться''' При обращении любым из способов Вам вам понадобится представиться: назвать ФИО и компанию, в которой Вы вы работаете. Возможно, продиктовать телефон и адрес электронной почты для обратной связи. В случае отсутствия данной информации (особенно по почте) специалисты технической поддержки, прежде чем начать решать проблему, сначала будут выяснять эту информацию, на что уходит драгоценное время. Мы не принимаем анонимки ни в каком виде! Особенно частая ошибка - ошибка — когда пользователи пишут с общей почты организации, вида "info«info@courier.ru" ru» и в подписи, вместо контакта человека написано что-то вроде "С «С уважением, команда курьерской службы"службы». Нужна конкретная заявка от конкретного человека: мы должны знать, с чем работаем.

*'''Предоставить полную информацию''' Очень важно предоставить исчерпывающую информацию о своем вопросе. Номер заказа, с которым возникла проблема, или название клиента, если проблема с клиентом. Обратите внимание: если проблема касается сразу группы заказов – заказов — это хорошо, что Вы вы например, заметили "Во «Во всех позавчерашних заказах происходит ..."…», и это даже может нам помочь, но номер конкретного заказа, хотя бы одного из той группы, нужно назвать. Сотрудник технической службы должен увидеть проблему, иначе может случиться так, что, просмотрев несколько заказов и не увидев никаких ошибок, он сочтёт, что дело в «человеческом факторе» и закроет тикет. Это абсолютно нормально и логично: люди ошибаются намного чаще машин! Если вопрос по отчету – отчету — укажите точную последовательность действий для его получения, какие пункты меню выбирали, какие данные вводили, приложите сам отчет. Если загружаете файлы – файлы — обязательно приложите исходные файлы и опишите, как загружаете. Будьте точны в формулировках! Неправильно сформулированное описание проблемы может привести к тому, что наш специалист будет искать возникшую проблему совсем не там, где она находится, и потеряет Ваше ваше и наше время. Например, после получения формулировки "В «В подключении дата стоит не такая" такая» последует вопрос о том, что же такое, в Вашем вашем представлении "подключение"«подключение», и эту потерю времени можно предотвратить, указав понятные нашим сотрудникам термины, а еще лучше – лучше — приложить скрин-шотскриншот, на котором было бы сразу видно, и какую именно Вы вы имеете в виду дату.

*'''Убедиться в создании задачи''' При любом обращении сотрудник технической поддержки должен создать так называемый "тикет" - «тикет» — это номер обращения по одному конкретному вопросу, в рамках которого решается Ваша задача. Тикет - Тикет — это крайне удобное средство контроля за выполнением задач, он гарантирует, что ни один вопрос не потеряется бесследно. О создании тикета Вам вам на электронную почту придет письмо. Так же, Вы Также вы можете просматривать свои тикеты в [https://home.courierexe.ru личном кабинете], и контролировать - контролировать — что делается, а на что от Вас вас ожидают реакции.

'''UPDATE''' В последнее время получил несколько вопросов о программе по Whatsapp'y Whatsapp’y на личный мобильный телефон с неизвестных номеров. Такие обращения сразу отмечаются как спам, и номера банятся. '''''Коллеги! Ну давайте уже уважать друг друга!'''''

===Контроль качества===Если Вы вы не удовлетворены качеством решения Вашего вашего вопроса, есть несколько способов повлиять на ситуацию:*'''Проголосовать по телефону''' После окончания телефонного разговора с нашими специалистами, система предлагает поставить им оценку.*'''Проголосовать из письма''' В письме об изменении тикета по Вашему вашему обращению Вам вам предлагают выбрать оценку.*'''Обратиться к директору''' По почте [mailto:admin@courierexe.ru admin@courierexe.ru] или, в экстренных ситуациях, даже телефону: +7 (916) 114-79-92. При обращении нужно представиться, назвать номер тикета и/или максимально точное время телефонного общения с нашими сотрудниками - я . Я лично подниму историю вопроса, записи телефонных разговоров, дам оценку ситуации и обязательно приму меры! Надо понимать, что голословные, не проверяемые, претензии вроде "я «я звонил когда-то, не помню когда, и мне плохо ответили" ответили» я принять не могу.

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

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

==Почему вы не сообщаете об изменениях?=====Текущие изменения функциональности и логики работы===

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

===Добавление новых функций===Мы постоянно добавляем новые функции, расширяющие возможности системы. Однако на работу такой функции оказывают влияние тысячи процессов, уже происходящих в системе. Поэтому мы вначале тестируем её на внутренних серверах, да и потом долгое время следим за корректностью её работы: собираем информацию об опыте использования, дописываем, улучшаем, переделываем. Поэтому, сразу после выхода новую функцию нет смысла документировать – документировать — она еще будет меняться и не раз. В случае возникновения погрешностей – погрешностей — в процессе эксплуатации они выявляются и устраняются. У программистов есть такая поговорка "Каждая «Каждая последняя ошибка, найденная в программе, на самом деле является предпоследней"предпоследней». Т.о. мы никогда не можем сказать, какой-то процесс идеален. Он может быть таковым до очередного улучшения, которое начнёт с ним конфликтовать, или возникновения ещё какой либо особой ситуации.

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

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

* Вся та функциональность, которая сейчас есть в системе, и которую вы приобретаете за смешные, для подобных систем, деньги, так же была до Вас вас кем-то придумана и оплачена, что позволяет вам сразу пользоваться всеми этими идеями.* Мы, естественно, не все доработки делаем платно. При принятии решения о стоимости и сроках выполнения доработки мы опираемся на множество факторов, таких, как востребованность (возможно, потенциальная) другими нашими клиентами, трудозатратность, реальная необходимость доработки именно для Вашего вашего процесса, обслуживаемость данной функциональности в будущем. И на практике, большинство доработок мы делаем по себестоимости. Некоторые — бесплатно, некоторые, если доработка нужна только вам, и больше о ней никто не спрашивал и подобных процессов больше ни у кого нет — то по рыночной цене. Бывают и такие доработки, за которые мы выставляем завышенный ценник, если видим, что подобная доработка может негативно сказаться на стабильности, скорости работы системы, ее масштабируемости. В этом случае ценой можно показать клиенту, что другое решение правильнее, дешевле, а клиент может, так же деньгами, сказать что ему это действительно нужно, что ему это выгодно, и он действительно будет этим пользоваться.

==Почему обновления платные==Вы купили систему и пользуетесь. В это время наши программисты работают, реализуют множество новых функций, улучшают существующие. Клиенты генерируют идеи, оплачивают их разработку, платят за поддержку, участвуют в тестировании новых функций. Согласитесь, не справедливо, если вы просто придете и все это даром получите? Так же сам процесс обновления связан с трудозатратами как на само обновление, так и дальнейшую поддержку. Обновление - Обновление — это когда что-то меняется. А значит пользователей нужно обучать. Возможно - Возможно — договариваться и перестраивать бизнес-процессы. Поэтому после обновления мы поддерживаем клиентов еще 2 недели. И чем больше времени прошло с последнего обновления - обновления — тем больше изменений, тем сложнее перейти на новую версию. Поэтому стоимость обновления зависит от времени, прошедшего с последнего обновления. Так же обновления входят в техническую поддержку по 2-му и 3-му тарифам. 

Как-то у нас спрашивали "А «А как же так не справедливо - справедливо — я купил программу год назад, и в ней не было такой функции. А сейчас она продается за те же деньги, уже с этой функцией, и те, кто покупают сейчас, ее получают бесплатно, а мне нужно заплатить за обновление"обновление». Объясняю: 10 лет назад за те деньги, за которые вы сейчас покупаете Iphone, продавались монохромные Siemens с кнопочками и полифонией. Но вы же не считаете, что зря купили тот старый телефон? Или что сейчас производители вас обманывают - обманывают — подсовывают мех гораздо лучше (с)? Вопрос в том, что товар или услуга, которую вы приобретаете в конкретном времени и месте, за конкретные деньги, на этот данный момент вам выгоден. Вы же посмотрели рынок, посчитали окупаемость и выбрали то, что наиболее эффективно будет приносить прибыль в вашем бизнесе. И весь этот год зарабатывали на этой системе, в отличие от того, кто ее только сейчас покупает. Ну и, конечно, это же очень хорошо, что наша система постоянно развивается. На самом деле, это даже происходит не в какой-то жесткой конкурентной борьбе, а просто наши клиенты обращаются с потребностями, а мы их решаем. И каждый день делаем работу всех наших клиентов все более эффективной. Мы работаем на то, чтобы все ваши конкуренты, у которых нет нашей системы остались за бортом! А те, у кого есть - есть — взаимовыгодно сотрудничали, и процветали.