Сложно подсчитать, т.к. нужно сначала отделить статических абонентов от перемещающихся, которых не стоит учитывать, поскольку абонент мог оказаться в переходе, в лифте и.т.д.
У Теле2 все прекрасно и скорость и доступность. Огорчает только полное отсутствие техподдержки коммуникационных устройств купленных не в Теле2.
Я от них пару месяцев назад на даче отказался. Стояла на маршрутизаторе резервного канала. С января по май все летало, даже SIP не лагал, но в один прекрасный момент, и именно тогда, когда это было очень нужно, счастье кончилось. По трассировке пинги уходили с моего маршрутизатора, проходили еще пару-тройку хопов и терялись. Несколько звонков в техподдержку заканчивались на «У Кас какой модем?» и при ответе «Хуавей» радостно сообщали, что поддержка оказывается только по их оборудованию, в остальных случаях советовали обращаться к производителю.
То, что проблема не в модеме, а в маршрутизации, причем именно для моей симки, было выше их понимания. Другая симка от Теле2 радостно работала.
Так что советую хорошо подумать. Я перешел обратно на мегафон. Там хоть SIP не работает, зато все остальное стабильно.
Эксплуатация сервера в обычной комнате тоже имеет свои минусы, зачастую значительные, типа сильного загрязнения за 2-3 года работы, в результате чего тихий сервер превращается в гудящего монстра. Тем более с такой плотной компоновкой. Пропылесосить тоже не всегда получается, т.к. для этого приходится выключать всю систему на час — другой. Да и сотрудники комнаты после прочистки сервера сжатым воздухом будут не слишком рады.
Ну, если только по открытым, то это чисто лабораторная работа, и нахрена ее в интернет выкладывать?
По крайней мере в Тучково есть отделение, в Кубинке отделение.
Я и не говорю про страндартные процессы. Речь как раз о том, что подходы к продаже стандартного готового решения и решения с высокой долей кастомизации разные. Подходы к продаже легковых автомобилей существенно отличаются от подходов к продаже спецтехники.
Разбиение на тематики — правильно, но как мне это поможет в процессе продажи СПР для грузоперевозчика?
Не стоит забывать еще и о копирайтах. Разработка тематической системы очень часто предполагает, что все права на доработки стандартных модулей принадлежат заказчику. А туда как раз и входят 90% интерфейсов, т.е. того, что можно показать на сайте.
50-75% это в случаях типового внедрения, а если приходится писать сложную логику, которую заказчик и сформулировать внятно не может, а также интегрировать со всякими внешними системами ( 1С, интернет-магазины поставщиков, всяческие НБКИ и Эквифаксы) то внедрение может составить и 500% от стоимости лицензий, плюс, возможно, еще такой же бюджет на последующее удовлетворение хотелок, появляющихся в процессе реализации.
Небольшая организация с одним офисом… договора/акты/фактуры… все это решает 1C/Sharepoint/Lotus Domino. Равно как и для регистрации входящих/исходящих. Это не документооборот, это просто учет документов.
Ну нет в небольших компаниях процессов, связывающих десятки подразделений по всей стране, с жесткими сроками реакции, изощренной системой безопасности и связей в реальном времени с множеством внешних сервисов. Маркетологи тяжелых систем документооборота показывают возможности платформы, поскольку функционал все равно придется писать внедренцам каждый раз заново в соответствии с задачами и бизнес логикой заказчика.
Ну как можно объяснить скриншотами, что система принятия решения о выплате пенсии в НПФ и система принятия решения о выдаче потребительского кредита в банке практически ничем не отличаются по архитектуре и возможностям, хотя в каждой их них совершенно разные поля и действия сотрудников, и взаимодействуют они с совершенно различными внешними сервисами?
А поподробнее можно про идеологию 80-х и серьезные доработки на этапе внедрения? Насколько я в курсе почтовая система разворачивается не менее быстро, чем на MS Exchange. СУБД не реляционная — это да, так как система заточена под обработку документов.
Лотус уже лет 10 как хоронят, и все похоронить не могут.
Тогда Вам надо быть готовым к тому, что софт на нем попадет под офисные стандарты. И самостоятельно ставить и настраивать Вы ничего не сможете. Затраты времени на переустановку криво установленного софта, с сохранением наработанных данных, могут быть в разы больше, нежели изначальная правильная настройка
Маркетингом и вложением в партнеров. IBMу в последнее время все барабану. Пытаются двигать какие-то мертворожденные технологии.
При том, что пока еще технологически MS Exchange не догоняет Domino, но в затылок дышит очень настырно.
Админов наверное нет, как и во многих других крупных зарубежных компаниях, но есть HelpDesk первого уровня, который и выполняет функции эникейщиков. Задача переустановки винды — это все таки не админская а эникейская.
Поскольку, до кучи занимаемся и аутсорсингом, то я немного в теме. Поэтому выскажу свое видение решения Ваших проблем:
1. От услуг данного аутсорсера отказаться однозначно.
2. Поискать аутсорсера или фрилансера который возьмется единоразово решить фиксированный объем Ваших текущих проблем и задокументировать IT инфраструктуру. В договоре должно быть четко зафиксировано, что должно быть задокументировано и каким образом поддерживается актуальность документации.
Принять у него работу. При этом идеальный вариант — принимать документацию должны не Вы, а Ваш представитель разбирающийся в IT, который с самого начала должен принять участие в разработке требований к документации. Это будет довольно дорого, но толк от этого будет.
3. Заключите договор с аутсорсером/фрилансером где разделите задачи на 2 категории — стандартные, решаемые за фиксированный срок и входящие в аобнплату и расширенные, решаемые за дополнительную плату. Пропишите штрафы за задержки в решении задач 1 категории. Пропишите обязательность актуализации документации по инфраструктуре IT. Расширенные задачи, кстати, можно отдавать и третьим специалистам. Не так уж много сисадминов умеют грамотно настроить тот же автокад. При систематических задержках — не подписывайте ежемесячные акты и пишите мотивированный отказ, с указанием нерешенных задач с сроков их решения по договору.
Поработать в компании на страте — это правильное решение. Правда хотя бы раз в пару месяцев у клиента появляться есть смысл.
Эникейщиком, в таких случаях выступает наиболее понимающий в компьютерах сотрудник офиса.
Я и написал, что реализовать не проблема, но при прочих равных, в данной задаче SQL предпочтительнее, т.к. просмотр отчетов довольно нерегулярное занятие и если мы будем обновлять вьюху при каждой записи в лог, то это потребует дополнительной мощности системы. Ведь логи пишуться постоянно. У меня http daemon на некоторых серверах добавляет до 1000 записей в секунду. Конечно, мы можем отключить постоянный апдейт вьюхи, но тогда при обращении к ней, к примеру раз в две недели вьюха будет перестраиваться довольно долго. Существенно дольше, чем отработает запрос к SQL таблице.
Решение просто как 3 копейки:
Система пишет лог в noSQL базу, а потом по расписанию несколько раз в сутки переносит поля в SQL таблицу. В результате я имею быстрый оперативный лог, который нужен в 90% случаев, и историю за полгода, требующую минимум места и не требующую ресурсов до обращения к ней. А это бывает не чаще раза в год.
а) не хотят плодить сущности
В оригинале сущности не стоит плодить без необходимости. А необходимость регулярно возникает.
б) в большинстве задач возникает рано или поздно проблема синхронизации дублированных данных в разных хранилищах
Довольно успешно решается при грамотном планировании на уровне архитектуры, когда четко определяется где конкретные данные первичные, и регулярной фоновой процедуре проверки целостности и необходимой синхронизации данных.
Хотите примеров? Их есть у меня.
Тупая запись и последующий анализ нескольких типов логов, линейный каталог оборудования на 10-15 млн записей.
Реализация несложная, а вот быстродействие Вас огорчит.
А вот тот же каталог оборудования с учетом вложенности ( Например: Участок водопровода сотоит из труб и колодцев, колодец состоит из крышки люка, задвижки и насоса, насос в свою очередь состоит из ряда деталей, сложная делать состоит из прокладок и других деталей и.т.д. ) проще реализовать на noSQL и вежливо попросить заказчика нарастить мощность оборудования.
Опытный экскаваторщик сумеет ковшом закрыть спичечный коробок, стоящий на земле, но в реальной жизни это быстрее сделать руками или ногой.
Я от них пару месяцев назад на даче отказался. Стояла на маршрутизаторе резервного канала. С января по май все летало, даже SIP не лагал, но в один прекрасный момент, и именно тогда, когда это было очень нужно, счастье кончилось. По трассировке пинги уходили с моего маршрутизатора, проходили еще пару-тройку хопов и терялись. Несколько звонков в техподдержку заканчивались на «У Кас какой модем?» и при ответе «Хуавей» радостно сообщали, что поддержка оказывается только по их оборудованию, в остальных случаях советовали обращаться к производителю.
То, что проблема не в модеме, а в маршрутизации, причем именно для моей симки, было выше их понимания. Другая симка от Теле2 радостно работала.
Так что советую хорошо подумать. Я перешел обратно на мегафон. Там хоть SIP не работает, зато все остальное стабильно.
По крайней мере в Тучково есть отделение, в Кубинке отделение.
Разбиение на тематики — правильно, но как мне это поможет в процессе продажи СПР для грузоперевозчика?
Не стоит забывать еще и о копирайтах. Разработка тематической системы очень часто предполагает, что все права на доработки стандартных модулей принадлежат заказчику. А туда как раз и входят 90% интерфейсов, т.е. того, что можно показать на сайте.
Ну нет в небольших компаниях процессов, связывающих десятки подразделений по всей стране, с жесткими сроками реакции, изощренной системой безопасности и связей в реальном времени с множеством внешних сервисов. Маркетологи тяжелых систем документооборота показывают возможности платформы, поскольку функционал все равно придется писать внедренцам каждый раз заново в соответствии с задачами и бизнес логикой заказчика.
Ну как можно объяснить скриншотами, что система принятия решения о выплате пенсии в НПФ и система принятия решения о выдаче потребительского кредита в банке практически ничем не отличаются по архитектуре и возможностям, хотя в каждой их них совершенно разные поля и действия сотрудников, и взаимодействуют они с совершенно различными внешними сервисами?
Лотус уже лет 10 как хоронят, и все похоронить не могут.
При том, что пока еще технологически MS Exchange не догоняет Domino, но в затылок дышит очень настырно.
Аутсорсят разработчики специализированного ПО? Тогда довольно реально, но не уверен, что в финансах выгоднее.
1. От услуг данного аутсорсера отказаться однозначно.
2. Поискать аутсорсера или фрилансера который возьмется единоразово решить фиксированный объем Ваших текущих проблем и задокументировать IT инфраструктуру. В договоре должно быть четко зафиксировано, что должно быть задокументировано и каким образом поддерживается актуальность документации.
Принять у него работу. При этом идеальный вариант — принимать документацию должны не Вы, а Ваш представитель разбирающийся в IT, который с самого начала должен принять участие в разработке требований к документации. Это будет довольно дорого, но толк от этого будет.
3. Заключите договор с аутсорсером/фрилансером где разделите задачи на 2 категории — стандартные, решаемые за фиксированный срок и входящие в аобнплату и расширенные, решаемые за дополнительную плату. Пропишите штрафы за задержки в решении задач 1 категории. Пропишите обязательность актуализации документации по инфраструктуре IT. Расширенные задачи, кстати, можно отдавать и третьим специалистам. Не так уж много сисадминов умеют грамотно настроить тот же автокад. При систематических задержках — не подписывайте ежемесячные акты и пишите мотивированный отказ, с указанием нерешенных задач с сроков их решения по договору.
Эникейщиком, в таких случаях выступает наиболее понимающий в компьютерах сотрудник офиса.
Решение просто как 3 копейки:
Система пишет лог в noSQL базу, а потом по расписанию несколько раз в сутки переносит поля в SQL таблицу. В результате я имею быстрый оперативный лог, который нужен в 90% случаев, и историю за полгода, требующую минимум места и не требующую ресурсов до обращения к ней. А это бывает не чаще раза в год.
В оригинале сущности не стоит плодить без необходимости. А необходимость регулярно возникает.
б) в большинстве задач возникает рано или поздно проблема синхронизации дублированных данных в разных хранилищах
Довольно успешно решается при грамотном планировании на уровне архитектуры, когда четко определяется где конкретные данные первичные, и регулярной фоновой процедуре проверки целостности и необходимой синхронизации данных.
Тупая запись и последующий анализ нескольких типов логов, линейный каталог оборудования на 10-15 млн записей.
Реализация несложная, а вот быстродействие Вас огорчит.
А вот тот же каталог оборудования с учетом вложенности ( Например: Участок водопровода сотоит из труб и колодцев, колодец состоит из крышки люка, задвижки и насоса, насос в свою очередь состоит из ряда деталей, сложная делать состоит из прокладок и других деталей и.т.д. ) проще реализовать на noSQL и вежливо попросить заказчика нарастить мощность оборудования.
Опытный экскаваторщик сумеет ковшом закрыть спичечный коробок, стоящий на земле, но в реальной жизни это быстрее сделать руками или ногой.