воскресенье, 15 марта 2015 г. - www.msmirnov.ru

Как генеральные IT-подрядчики сбивают цены

В настоящее время на IT-рынке существуют крупные компании-посредники, часто выступающие генеральными подрядчиками крупных государственных, полу-государственным и коммерческих проектов.

Зачастую основная задача таких компаний при реализации подобных заказов - это выполнение проектов с получением максимальной маржи от передачи проектов на субподряд. Их наценка в таких случаях может достигать 400%. Наверное, бывает и больше, но я максимум видел 400%.

Для того, чтобы максимально сбить цены субподрядчиков генеральными подрядчиками используются следующие приемы:
  1. Устраивается тендер между несколькими субподрядчиками. Сроки тендера при этом максимально сжимаются, чтобы у субподрядчиков не было достаточно времени выявить и обсудить все нюансы Технического Задания.
    Позднее, когда не выявленные на этапе тендера сложности приведут к увеличению бюджета проекта, оплачивать их реализацию придется субподрядчику, так как он будет обвинен в недостаточном внимании к деталям при оценке.

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

  4. При рассмотрении проектного предложения от субподрядчика требуется разбивка стоимости по работам внутри проекта и ролям, необходимым для выполнения этих работ.
    При изучении состава работ ставится под сомнение необходимость привлечения тех или иных специалистов, а также их плановые трудозатраты.
    В результате уступок со стороны субподрядчика цена здесь также сбивается, а субподрядчик при этом, идя на эти уступки, все равно остается ответственным за свою финальную оценку проекта и будет обязан оплатить превышение бюджета из своего кармана, если такое будет иметь место.
    Здесь осуществляется умелое лавирование между принципами Fix Price и Time-and-Material - опять же с целью сбить цену.
    Оценка идет по принципу Time-and-Material, оплата по Fix Price.  

  5. Субподрядчику предлагается выполнить проект с минимальной ценой, с целью зарекомендовать себя, продемонстровать свои умения и уже потом, после того, как он зарекомендовал себя, работать по более высоким ставкам.
    Однако, с течением времени это не приводит к увеличению ставок, так как субподрядчик переходит от одного тендера к другому и каждый раз ему предлагается заново показать себя теперь уже для нового конечного заказчика или новой команды управления.

  6. Договор с посредником составляется так, что основные его пункты носят рамочный характер.
    Это приводит к тому, что более поздние конкретные договоренности, изменения и согласования происходят на словах или в переписке. Благодаря этому генеральные подрядчики могут менять условия игры в любой момент по своему усмотрению в каждой конкретной ситуации с максимальной выгодой для себя.
    Зачастую это приводит к неполной оплате проведенных работ под удобными предлогами.
Все эти приемы, используемые в совокупности, дают мощный механизм для снижения цены проектов до нулевой или даже отрицательной рентабельности, высасывания ресурсов и обескровливания субподрядчиков, а после - переключения на новых субподрядчиков.
Мой сайт - www.msmirnov.ru

суббота, 7 марта 2015 г. - www.msmirnov.ru

Концепция автоматизированной системы управления физическим размещением данных на MS SQL Server

В этом материале я хочу рассказать о принципиальной структуре и концепции системы управления физическим расположением данных, построенной на базе MS SQL Server.
Данную концепцию можно использовать при наличии задачи построения системы подобного рода. Я надеюсь, что материал окажется полезным тем, кто сам столкнется с такой тематикой. Если по прочтении статьи у кого-либо появится потребность в более детальном рассмотрении тех или иных вопросов построения такой системы, я буду рад это сделать.

Основной задачей такой системы является сокрытие от конечного пользователя физического места расположения данных, управление их физическим расположением, обслуживание данных, мониторинг состояния и т.п.

Систему необходимо строить так, чтобы пользователь (человек или процесс), выполняя запросы на получение или запись данных, не знал о том, где физически они хранятся - система должна скрывать их физическое расположение и сама решать вопросы распределения данных и выдачи их пользователю.

Структуру такой системы можно изобразить на диаграмме:



Как видно на диаграмме, система разделена на 4 части:
  • Управление расположениями - часть системы, отвечающая за создание, удаление, подготовку к использованию и обслуживание хранилищ данных.  Именно эта часть система отвечает за управление физическим расположением данных.
  • Подсистема безопасности - часть системы, ответственная за управление правами доступа к данным.
  • Интерфейс администрирования - часть системы, предоставляющая администратору возможность управлять ее работой.
  • API - программный интерфейс системы, позволяющий сторонним приложениям получать доступ к хранящимся данным.
Все данные, расположением которых управляет такая система, можно разделить на типы.
Типом данных может быть что угодно, например - список клиентов, история заказов, история просмотров - в общем, что угодно.
Каждый тип данных при этом обладает своей структурой - списком атрибутов, определяющих какие именно данные хранит каждый тип.


Задачи подсистемы "Интерфейс администрирования".
  1. Позволять регистрировать в системе новые типы данных, определять их структуру (имена атрибутов, их типы и другие свойства).
  2. Регистрировать в системе новые физические сервера для размещения данных
  3. Задавать настройки расположение данных на каждом сервере
  4. Управлять настройками распределения данных между серверами
  5. Управлять настройками прав доступа

Задачи подсистемы "Управление расположением".
  1. Заблаговременно и по требованию пользователя создавать на физических серверах базы данных, таблицы, элементы партицирования и пр. для размещения данных
  2. Исправлять ошибки, возникающие в процессе работы - обрывов связи, сбоев в работе серверов и т.п.
  3. Проводить публикацию новых данных, если она требуется
  4. Выполнять дефрагментацию и переиндексацию
  5. Удалять устаревшие данные
  6. Управлять распределением данных между серверами

Задачи подсистемы безопасности.
  1. Управление доступом на запись и чтение данных
  2. Управление пользовательскими сессиями, мешающими работе с данными


Задачи подсистемы API.
  1. Выдавать конечным потребителям данные, хранящиеся в системе
  2. Принимать от потребителей новые данные, которые необходимо поместить в систему
  3. Получать от потребителей сигналы о необходимости выполнения публикации переданных данных
  4. Обеспечение параллельной работы пользователей с системой

В заключении хочу сказать что тема построения таких систем весьма обширна и здесь даны лишь самые общие наброски в направлении их создания.

Мой сайт - www.msmirnov.ru