Как много умеющих предвидеть,
и как мало умеющих предупредить!
Веслав Брудзиньский
Веслав Брудзиньский
В этой статье я попытаюсь забыть, что я — разработчик программы для автоматизации турагентств, и представить себя в роли руководителя турфирмы, выбирающего программу для автоматизации своего предприятия. Итак, как же я буду выбирать себе программу?Разумеется, я начну с того, что составлю список программ, которые на рынке представлены. Начну знакомиться с сайтами производителей и описаниями программных продуктов. И отберу те программы, с которыми имеет смысл познакомиться поближе. На что же я буду обращать внимание при первом чтении?
Готовность производителя софта к сотрудничеству
Это, пожалуй, самое важное. В туризме постоянны только изменения, а значит, постоянный внос изменений в программу неизбежен. И очень важно оценить, а не останемся ли мы один на один с программой? Сможем ли мы заказать необходимые нам изменения в программе?
Крайне важно, что сайт сообщает о возможном участии разработчика во внедрении программы. Если сайт даёт понять, что поставка программы идёт по принципу «Дайте деньги и отвалите!», то есть я получу коробку с дисками и описаниями, и начну мучительно вникать, что же с этим всем делать — лучше отказаться от покупки этой программы сразу. Производитель софта для туристической фирмы обязательно должен предлагать услугу по внедрению, пусть даже за приличные деньги.
Крайне важно, что сайт сообщает о возможном участии разработчика во внедрении программы. Если сайт даёт понять, что поставка программы идёт по принципу «Дайте деньги и отвалите!», то есть я получу коробку с дисками и описаниями, и начну мучительно вникать, что же с этим всем делать — лучше отказаться от покупки этой программы сразу. Производитель софта для туристической фирмы обязательно должен предлагать услугу по внедрению, пусть даже за приличные деньги.
Очень большими плюсами являются наличие форума пользователей на сайте и наличие службы техподержки.
Нет ли ограничения на число пользователей?
Как ни странно, у некоторых программ до сих пор существуют ограничения на число пользователей. Такие ограничения в прошлом веке порождались соображениями маркетинга. Но в наши дни всё гораздо серьёзней: как правило, это уже ограничения технологий, на которых создавалась программа.
Поищите информацию о допустимом числе пользователей на сайте производителя программы. Если не нашли — это веский повод связаться с их службой поддержки. Заодно оценить, насколько качественно и оперативно она работает.
Поищите информацию о допустимом числе пользователей на сайте производителя программы. Если не нашли — это веский повод связаться с их службой поддержки. Заодно оценить, насколько качественно и оперативно она работает.
Долго ли существует программа (да и разработчик)?
Насколько решения (и фантазии на темы туризма) разработчика опробованы и проверены? Или Вы первый, на ком он будет ставить свои опыты?
Познакомимся поближе
Итак, обзваниваем производителей программ для туризма и договариваемся о визите к ним.
Возможно, что представители фирмы-производителя готовы сами приехать и всё показать, но есть два довода всё-таки поехать к ним в офис:
1. Слишком велика вероятность, что я буду смотреть, как «брюки превращаются... превращаются...» — то есть на лихорадочную адаптацию программы к моим офисным компьютерам.
2. Не дадут мне в моём офисе спокойно посмотреть демонстрацию.
Так что выезжаю к производителю, преудсмотрительно забыв в офисе мобил.
Прослушаю презентацию, не перебивая (ну разве что попрошу сконцентрироваться на программе и её возможностях, если рекламное вступление угрожающе затягивается). А затем вежливо задам вопросы.
Доступно ли будет мне своими силами вносить изменения в программу?
Самый важный вопрос. Ибо всё постоянно меняется. Особенно формы бланков, которые ждёт от нас государство. А если я захочу внедрить не предусмотренный программой вид услуги с некоторыми специфическими параметрами — как я могу это сделать?
Если никак — тогда плохо. Я бы дальше спрашивал только в том случае, если бы меня заверили, что я (ну или мой программист), если надо, внесу изменения в программу. Признаться, не хочется в критический момент услышать от разработчика что-то вроде: «Но, ребята, кто обещал кормить вас в дороге?».
Фрагмент статьи, содержащий этот суровый вопрос, заслуживает того, чтоб привести его полностью. Прочитайте и представьте, что Вам срочно нужны изменения в программе, а разработчик отвечает Вам:
Ну, все замечательно, купили, научились, работаем. Но тут вышел новый закон, директор решил заняться и внутренним туризмом тоже или продажей авиабилетов. Или вы поняли, что для абсолютного счастья не хватает конкретной экранной формы. Или сгорело железо, и софт перестал работать. И вы с огорчением обнаруживаете, что за новую "светлую жизнь" снова надо платить деньги этим хапугам-программистам. Но, ребята, кто обещал кормить вас в дороге? Когда вы приезжаете на очередное техобслуживание в автосервис, у вас даже мысли не возникает о его бесплатности. [разумеется, о гарантийном обслуживании, устранении неисправностей за счёт производителя и отзывах автомобилей мы и слыхом не слыхивали — Ю.М.] Или меняя обычные колеса на литые диски, вы безропотно отдаете свои кровные. С автоматизацией та же картина. Вы платите деньги за совершенно конкретный продукт, умеющий делать то-то и то-то. Новые версии с новыми возможностями, сервисное обслуживание продукта - все это стоит денег. Да, ребята, программы, как и авто, тоже требуют сопровождения. И поверьте: нам эти деньги достаются с не меньшим трудом, чем вам.
С такими настроениями производителей всё-таки спокойней, когда есть исходный код программы.
Много ли придётся дорабатывать?
Я как раз захватил с собой реальные заявки. Итак, Вот Вам моя заявка. Вносите.
Разумеется, я не буду паниковать, если что-то внести не удаётся. Потому что... я это наперёд знал. Ничего страшного в этом нет. Теперь надо интересоваться, во что обойдётся адаптация к моим условиям.
Если меня начнут уверять, что мне лучше изменить эти условия, чтоб легче было работать программе, мне станет грустно. Но будем оптимистами: сроки и стоимость разработки будут ориентировочно оценены, так что можно задать следующий вопрос.
Работа с программой нескольких офисов
Программ, не способных работать в локальной сети, я не видел уже много лет. На всякий случай, извинившись, уточню этот вопрос, мы с разработчиком весело посмеёмся, вспомним молодость (как коаксиал кидали по плинтусу...), и перейду к важному вопросу: как обеспечить работу нескольких офисов с программой?
Я не буду останавливаться на вариантах, которые, с моей точки зрения, в нашем веке уже не имеют права на существование. Итак, какие разумные варианты могут быть предложены?.
1. Общая база данных на сервере, доступном по Интернет (или VPN). То есть все работают с единой базой данных. Удобно с точки зрения оперативной работы с данными, но неоптимально с точки зрения разграничения доступа и быстродействия.
2. Каждый офис работает со своей, локальной базой данных, и организована периодическая репликация (обмен данными) между ними — через Интернет или как-то иначе. Удобно с точки зрения разграничения доступа и быстродействия, но оперативная работа с данными затруднена или вообще невозможна.
3. Каждый офис работает со своей базой данных, находящейся на едином сервере баз данных. Это позволяет работать, не мешая данным других офисов, при этом все данные при необходимости доступны программе.
Я глубоко убеждён, что следует идти по третьему пути. Потому что одновременно решаются задачи разграничения доступа (чтоб сотрудники одного офиса не портили жизнь другим) и задачи единого управления данными (они все в одном месте, управляются одним и тем же программным кодом).
Можно ли минимизировать накладные расходы?
В своей статье Возможности экономии при автоматизации туристической организации я рассказываю о способах минимизации накладных расходов на внедрение. Поможет ли рассматриваемая программа их избежать (а это тысячи долларов!)?
Вместо заключения
Размеется, есть и другие критерии, которыми я буду руководствоваться. Но они, во-первых, субъективны, во-вторых, трудно формализуемы (например, мои симпании/антипатии). В этой небольшой статье я перечислил те вопросы, которые необходимо задать, и отрицательные ответы на которые должны Вас крайне насторожить. Но моя статья не заменит Ваш ум, интуицию и вкус. Вам решать.
Доступно ли будет мне своими силами вносить изменения в программу?
Самый важный вопрос. Ибо всё постоянно меняется. Особенно формы бланков, которые ждёт от нас государство. А если я захочу внедрить не предусмотренный программой вид услуги с некоторыми специфическими параметрами — как я могу это сделать?
Если никак — тогда плохо. Я бы дальше спрашивал только в том случае, если бы меня заверили, что я (ну или мой программист), если надо, внесу изменения в программу. Признаться, не хочется в критический момент услышать от разработчика что-то вроде: «Но, ребята, кто обещал кормить вас в дороге?».
Фрагмент статьи, содержащий этот суровый вопрос, заслуживает того, чтоб привести его полностью. Прочитайте и представьте, что Вам срочно нужны изменения в программе, а разработчик отвечает Вам:
Ну, все замечательно, купили, научились, работаем. Но тут вышел новый закон, директор решил заняться и внутренним туризмом тоже или продажей авиабилетов. Или вы поняли, что для абсолютного счастья не хватает конкретной экранной формы. Или сгорело железо, и софт перестал работать. И вы с огорчением обнаруживаете, что за новую "светлую жизнь" снова надо платить деньги этим хапугам-программистам. Но, ребята, кто обещал кормить вас в дороге? Когда вы приезжаете на очередное техобслуживание в автосервис, у вас даже мысли не возникает о его бесплатности. [разумеется, о гарантийном обслуживании, устранении неисправностей за счёт производителя и отзывах автомобилей мы и слыхом не слыхивали — Ю.М.] Или меняя обычные колеса на литые диски, вы безропотно отдаете свои кровные. С автоматизацией та же картина. Вы платите деньги за совершенно конкретный продукт, умеющий делать то-то и то-то. Новые версии с новыми возможностями, сервисное обслуживание продукта - все это стоит денег. Да, ребята, программы, как и авто, тоже требуют сопровождения. И поверьте: нам эти деньги достаются с не меньшим трудом, чем вам.
С такими настроениями производителей всё-таки спокойней, когда есть исходный код программы.
Много ли придётся дорабатывать?
Я как раз захватил с собой реальные заявки. Итак, Вот Вам моя заявка. Вносите.
Разумеется, я не буду паниковать, если что-то внести не удаётся. Потому что... я это наперёд знал. Ничего страшного в этом нет. Теперь надо интересоваться, во что обойдётся адаптация к моим условиям.
Если меня начнут уверять, что мне лучше изменить эти условия, чтоб легче было работать программе, мне станет грустно. Но будем оптимистами: сроки и стоимость разработки будут ориентировочно оценены, так что можно задать следующий вопрос.
Работа с программой нескольких офисов
Программ, не способных работать в локальной сети, я не видел уже много лет. На всякий случай, извинившись, уточню этот вопрос, мы с разработчиком весело посмеёмся, вспомним молодость (как коаксиал кидали по плинтусу...), и перейду к важному вопросу: как обеспечить работу нескольких офисов с программой?
Я не буду останавливаться на вариантах, которые, с моей точки зрения, в нашем веке уже не имеют права на существование. Итак, какие разумные варианты могут быть предложены?.
1. Общая база данных на сервере, доступном по Интернет (или VPN). То есть все работают с единой базой данных. Удобно с точки зрения оперативной работы с данными, но неоптимально с точки зрения разграничения доступа и быстродействия.
2. Каждый офис работает со своей, локальной базой данных, и организована периодическая репликация (обмен данными) между ними — через Интернет или как-то иначе. Удобно с точки зрения разграничения доступа и быстродействия, но оперативная работа с данными затруднена или вообще невозможна.
3. Каждый офис работает со своей базой данных, находящейся на едином сервере баз данных. Это позволяет работать, не мешая данным других офисов, при этом все данные при необходимости доступны программе.
Я глубоко убеждён, что следует идти по третьему пути. Потому что одновременно решаются задачи разграничения доступа (чтоб сотрудники одного офиса не портили жизнь другим) и задачи единого управления данными (они все в одном месте, управляются одним и тем же программным кодом).
Можно ли минимизировать накладные расходы?
В своей статье Возможности экономии при автоматизации туристической организации я рассказываю о способах минимизации накладных расходов на внедрение. Поможет ли рассматриваемая программа их избежать (а это тысячи долларов!)?
Вместо заключения
Размеется, есть и другие критерии, которыми я буду руководствоваться. Но они, во-первых, субъективны, во-вторых, трудно формализуемы (например, мои симпании/антипатии). В этой небольшой статье я перечислил те вопросы, которые необходимо задать, и отрицательные ответы на которые должны Вас крайне насторожить. Но моя статья не заменит Ваш ум, интуицию и вкус. Вам решать.
Удачного выбора!
