Есть ли какие-либо количественные ограничения на номерную емкость?
Доступны ли политики групп сотрудников по фиксации звонков в CRM-системе? Например — как-либо особо фиксировать звонки из определенного отдела определенным контрагентам.
Не совсем соглашусь со следующим утверждением: «Экстремально нагруженные процессы могут использовать столько мощностей, что переход на другой сервер в случае краха системы станет невозможным.»
Это и с физическим сервером возможно в случае краха системы. В любом случае, необходима перезагрузка системы с изоляцией от источника экстремально нагруженных процессов.
Удачное сотрудничество разработчиков сервиса и вендора. Чаще, к сожалению, приходится работать иначе — решая самостоятельно вопросы от моделирования бизнес-процессов до конфигурирования среды на сервере. Долгими зимними вечерами в глубинах консоли:)
Взаимосвязь программных продуктов, по нашему опыту, процесс весьма непростой: всегда возникает множество неожиданных нюансов. Тем более прискорбно наблюдать, что такие существенные проблемы наблюдаются даже при интеграции родственных продуктов, если чуть отступить от стандартных способов и связей.
Соглашусь с авторами предыдущих комментариев. Некорретно утверждать, что это уязвимость самого почтового сервера Microsoft Exchange, тут нужно уточнить способы атаки и возможности подмены DLL-файла.
Пример интересный.
Из всего, что пробовали, wkhtmltopdf самая быстрая и корректная утилита. А header-html и footer-html нужны, там элементы фирменного бланка с графикой.
Мы решали задачи конвертации прайса с тысячами позиций. Миллиона там не предполагалось. Будет миллион — будем генерировать в фоне, задействуем LaTeX. На VDS кстати еще быстрее, чем на пустой машине, работает.
Есть два варианта печатной формы прайс-листа: HTML и PDF. Обе показываем людям, кому в чем удобнее, в том и смотрят. PDF-версия фактически формируется из шаблона для HTML-версии. Соответственно, быстрее тиражируются изменения шаблона, если они требуются.
При работе с FPDF и подобными библиотеками приходилось конвертировать русские ttf-шрифты в удобный ей формат, чтобы кириллица заработала в принципе. В MPDF это уже было сделано изначально.
Пока не исправлено, ячейки режутся неровно. Где это критично и размер ячейки предсказуем, вынуждены предварительно разбивать таблицу на несколько таблиц, по числу страниц. Где некритично — оставляем как есть.
Часто единой старой системы нет, заказчик работает в нескольких разных системах и испытывает трудности со сбором итоговой отчетности. Тогда поэтапное внедрение проходит логично и без хаоса. Иначе — да, получается, что запускать целиком всю систему, и работать в ней параллельно со старой до полной отладки новой.
По нашему опыту, оптимальна поэтапная автоматизация: т.е. сначала внедряется один блок системы, после чего собираются все возможные нюансы и доработки системы, и при этом архитектор системы общается с заказчиком, вплоть до того, что наблюдает за работой сотрудников заказчика в нашей системе, или в предыдущей чужой системе. После всех корректив есть смысл переходить к внедрению следующего блока.
В разделе Работа службы поддержки заслуживает упоминания продукт OsTicket (http://osticket.com), по нему доступно русское сообщество http://osticket.ru/. Продукт подлежит установке в облако и позволяет автоматизировать работу службы технической поддержки, в том числе сбор заявок с ящиков электронной почты, сортировку их по отделам и сотрудникам, автоматическую и ручную отправку ответов из системы. Также доступна аналитика по обработке заявок.
Как раз в том и принципиальный вопрос, кто делает резервное копирование и отвечает за результат. За свои серверы мы отвечаем и обеспечить сохранность данных можем, а за чужие-нет. В случае облачной системы резервное копирование действительно централизованное, в отличие от клиентской установки системы.
Мы не раскрываем причин и не комментируем действий наших заказчиков. Есть ряд схожих разумных требований — мы их реализуем.
Этот сервер под управлением заказчика. Копирование настроить конечно возможно, но в общем случае полная ответственность за копирование и его результаты не может лежать на нас по ряду не зависящих от нас же факторов, например, при каких-либо технических накладках не на нашем оборудовании, при необдуманных действиях системных администраторов заказчика и т.п.
По своему практическому опыту внедрения систем отметим, что часто бывает оптимальным поэтапное разворачивание и внедрение. Т.е. сделали первый этап, запустили, внедрили, собрали все возможные подводные камни, внесли доработки, затем приступаем к следующему этапу. Так и клиенты постепенно переучиваются.
Хотелось бы отметить, что в бесплатной пробной облачной версии Битрикс 24 отсутствуют многие описанные в статье «лишние» функции корпоративного портала, а управление задачами реализовано на вполне интуитивном уровне. Контролировать выполнение задач в сфере малого бизнеса в этой CRM-системе достаточно удобно.
Мы не комментируем наших заказчиков.
Я дал ответ: главные представители ряда заказчиков не хотят запоминать несколько логинов, но не могут использовать единый вход в несколько доступных им систем по ряду внутренних причин.
Десктопные системы — не совсем корректно выразился. Речь об устанавливаемом на сервере у заказчика ПО. Взять то же 1С Предприятие.
А нашим заказчикам нужно с точностью до наборот — разные пароли на одну учетную запись в разных системах. Причем, чтобы при работе в системе А не было ни намека на доступ в систему Б, но — при одинаковых логинах в двух системах. Может, в системе А собственник вредный дышит в плечо и ему нельзя показывать систему Б, или какие-то иные внутренние соображения.
Это не противопоставление, а в целом даже сравнение. В статье описан обзор мер защиты наших облачных систем. Многие из этих мер неосуществимы для десктопных систем, например, централизованное резервное копирование.
Доступны ли политики групп сотрудников по фиксации звонков в CRM-системе? Например — как-либо особо фиксировать звонки из определенного отдела определенным контрагентам.
Это и с физическим сервером возможно в случае краха системы. В любом случае, необходима перезагрузка системы с изоляцией от источника экстремально нагруженных процессов.
Из всего, что пробовали, wkhtmltopdf самая быстрая и корректная утилита. А header-html и footer-html нужны, там элементы фирменного бланка с графикой.
Есть два варианта печатной формы прайс-листа: HTML и PDF. Обе показываем людям, кому в чем удобнее, в том и смотрят. PDF-версия фактически формируется из шаблона для HTML-версии. Соответственно, быстрее тиражируются изменения шаблона, если они требуются.
Этот сервер под управлением заказчика. Копирование настроить конечно возможно, но в общем случае полная ответственность за копирование и его результаты не может лежать на нас по ряду не зависящих от нас же факторов, например, при каких-либо технических накладках не на нашем оборудовании, при необдуманных действиях системных администраторов заказчика и т.п.
Я дал ответ: главные представители ряда заказчиков не хотят запоминать несколько логинов, но не могут использовать единый вход в несколько доступных им систем по ряду внутренних причин.
Десктопные системы — не совсем корректно выразился. Речь об устанавливаемом на сервере у заказчика ПО. Взять то же 1С Предприятие.
Это не противопоставление, а в целом даже сравнение. В статье описан обзор мер защиты наших облачных систем. Многие из этих мер неосуществимы для десктопных систем, например, централизованное резервное копирование.