• IoT 0.1 Весь интернет вещей в Вашем смартфоне

      image Перерыв тонны материала по текущему видению интернета вещей, сделал вывод — мы пытаемся объять необъятное. Авторитетные компании изобретают новые технологии коммуникаций, стандарты передачи данных, операционные системы и “железо” для умных устройств, забывая о первоначальной цели — о конечном потребителе. А наиболее прибыльным конечным потребителем является не “гик”, умеющий за час собрать умный чайник на новомодной платформе стоимостью >200$, а рядовой обыватель с довольно простыми потребностями:
      1. Контроль;
      2. Получение оперативной информации;
      3. Аналитика.

      При этом устройства из мира интернета вещей должны быть:
      1. Максимально дешевыми;
      2. Максимально автономными;
      3. Простыми в развертывании и использовании;

      Цель статьи — обозначить функциональные границы решения инфраструктуры интернета вещей в рамках текущих технических возможностей и согласно текущих потребностей конечного потребителя.
      Поехали
    • Ложные цели проектной команды


        Цель это основополагающий механизм, который имеет непосредственное влияние на структуру и поведение системы. Каждый модуль (участник) системы может работать в рамках единого механизма и получать от этого собственную выгоду, но если каждый из участников будет преследовать собственные цели, получится не система, а еще одна басня от известного автора.
        В проектах внедрения стороннего ПО в информационную систему предприятия проблема единого видения стоит особенно остро. В таких проектах обычно много участников:
        • Бизнес, который ставит целью извлечь максимальную выгоду от внедряемой автоматизации;
        • Подрядчик, цель которого извлечь материальную выгоду от внедрения;
        • Собственная команда разработки заказчика, которая стремится к минимизации трудозатрат и ответственности;
        • Конечные потребители системы, которые имеют потребность защиты от изменений.

        И разность целей зачастую приводит к несостоятельности продукта, «сваренного» в данном котелке противоречивых идей.
        В данной статье на наглядном примере рассмотрим негативные процессы, к которым приводит противоречивость целей. Рассматриваемый в нашем кейсе проект – внедрение ERP системы.
        Читать дальше →
      • Прототип «Инкубатора идей»

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

          Перед презентацией продукта необходимо описать предметную область.
          Свой продукт позиционирую как инструмент для «инкубации» идей. В последнее время стало модным понятие «инкубатора стартапов», но что делать тем, кто еще не дорос от идеи до стадии стартапа? В связи с этим у меня родилось предположение – многие идеи умирают, оставаясь без поддержки сильной команды. Задача понятна, проблема обрисована.

          Для первой итерации я предлагаю инструмент для инкубации идей и поиска персонала, который в дальнейшем может вырасти до полноценного сервиса, предлагающего следующий ряд услуг:
          1) Бизнес и системный анализ идеи;
          2) HR менеджмент и поиск персонала для стартапа.
          3) Поиск интересных проектов для соискателя.
          Читать дальше →
        • Опрос. Все ли наступают на грабли ERP

            Заранее прошу прошения за краткий и не очень полезный топик, но пришло время хотя-бы для себя расставить точки над И.
            На данный момент работаю в проекте интеграции известной и мега дорогой ERP системы в текущий информационный ландшафт предприятия. Помимо сжатых сроков, отсутствия компетентных консультантов, а в следствии качественной документации и общего виденья системы у нас возникает ряд серьезных трудностей.
            Основная проблема заключается в том, что время когда подрядчик с красивой улыбкой рассказывал как замечательно влезают все наши процессы в их систему прошло. Теперь же идет ожесточенная борьба за место под солнцем, а именно — кто должен делать автоматизацию, того что нет в их системах. Начинаются серьезные бои за покупку новых модулей, которые не были предусмотрены бюджетом, но без которых нам будет очень плохо.
            Одна из причин такого коллапса — со стороны предприятия не было эксперта по данным системам, который на начальной стадии проекта мог бы спустить с небес на землю ошарашенных великими возможностями системы пользователей и сказать свое фэ некоторым обещаниям подрядчика.
            Если у кого был крупный проект внедрения ERP системы, прошу под кат ответить на несколько вопросов.
            Читать дальше →
          • Начало системной архитектуры. Философия и язык. Часть 1

            image Скажу сразу – я начинающий архитектор, который переучивается данному ремеслу с системного администрирования.

            В данной статье не будет рассуждений на следующие тематики:

            • Как меня занесло в данную отрасль и беды системного администрирования;
            • Наличие/отсутствие вменяемой литературы и статей, школы системных архитекторов;
            • Как я себя чувствую на новой должности и планы на будущее и т.д.

            Вводную часть начну с моего ограниченного понимания места архитектора в крупной компании.

            В отделе информационных технологий присутствует множество участников процесса сопровождения и разработки ПО: программисты различных направлений, аналитики, тестировщики, администраторы систем, техподдержка разных уровней и т.д. Каждый из них видит либо часть системы, либо целую систему, но со своей точки зрения (к примеру, специалист технической поддержки первого уровня «видит» систему как продвинутый пользователь).
            Читать дальше →