👋 
Sprawdź, jak mogę Ci pomóc!

Wynikiem pracy analityka i projektanta przed rozpoczęciem implementacji jest Opis Techniczny Rozwiązania.

Przed wdrożeniem powstaje Opis Techniczny Rozwiązania w metodyce MDA (Model Driven Architecture). Definiuje on cele biznesowe oraz logikę działania systemu przy użyciu standardowych notacji (BMM, BPMN, UML, SBVR). Dokument ten jest utworem chronionym prawem autorskim i stanowi know-how Zamawiającego.

Opisane modele stanowią wiążące Wymagania. Nie narzucają technologii, lecz precyzują logikę, którą musi realizować oprogramowanie.

Składając ofertę, zadaniem Wykonawcy jest opracowanie Koncepcji Wdrożenia (studium wykonalności), która musi zostać zaakceptowana przez Zamawiającego przed rozpoczęciem prac programistycznych.

Kryterium sukcesu są testy odbiorcze, polegające na przeprocesowaniu dokumentów testowych zgodnie z modelami procesów biznesowych zawartymi w dokumentacji. Zgodność z modelem oznacza odebranie prac.

Rysunek. Przykładowy spis treści OTR.

Moja strategia wdrażania dowolnych rynkowych systemów (np. ERP, CRM, WMS, TMS...) jest prosta:

1. Stosuję jasny podział: gotowe oprogramowanie wdrażam tam, gdzie procesy są standardowe i regulowane prawem (finanse, kadry, księgowość) – tu nie buduje się przewagi, więc opłaca się kupić gotowy system. Natomiast obszary stanowiące o unikalności firmy i jej przewadze rynkowej obsługuję rozwiązaniami dedykowanymi.

2. Wdrożenie rozumiem jako parametryzację i konfigurację, a nie ingerencję w kod źródłowy (kastomizację). Jeśli system nie posiada wymaganej funkcji, projektuję zewnętrzny, dedykowany moduł i integruję go. Celem jest uniknięcie problemów z aktualizacjami (upgrade), zachowanie gwarancji producenta oraz eliminacja ryzyka uzależnienia od jednego dostawcy (vendor lock-in).

3. Zamiast jednego monolitycznego "systemu do wszystkiego", preferuję architekturę zorientowaną na usługi i dobór najlepszych systemów dziedzinowych. Integracja polega na wymianie komunikatów między niezależnymi systemami, a nie na współdzieleniu bazy danych. Daje to elastyczność i pozwala wymieniać poszczególne elementy układanki bez ruszania całości.

4. Wybór oprogramowania jest dla mnie ostatnim, a nie pierwszym krokiem. Zaczynam od modelowania organizacji i projektowania zamiast spisywania "listy życzeń" użytkowników. Następnie przeprowadzam analizę dopasowania potrzeb do oprogramowania (nigdy odwrotnie!)

Kładę duży nacisk na to, aby Zamawiający posiadał pełne autorskie prawa majątkowe do wszelkich rozwiązań dedykowanych i rozszerzeń. Umowa musi wyraźnie oddzielać licencję na użytkowanie od praw do elementów unikalnych, co chroni know-how firmy i zapewnia niezależność.

Zachęcam wszystkie organizacji do uporządkowania nieoczywistych podstaw takich jak:

• efektywne wykorzystywanie edytorów tekstu
• efektywne wykorzystywanie arkuszy kalkulacyjnych
• wykorzystywania narzędzi do zarządzania projektami i pracą własną

Dzielę się taką wiedzą za darmo:

Kursy

Prawa własności intelektualnej w IT mogą, ale nie muszą być skomplikowane.

Wedle mojej wiedzy i stanu prawnego możemy chronić naszą własność intelektualną w IT. Wystarczy pamiętać o tym, że:

• aby chronić know-how organizacji, należy je odpowiednio utrwalić
• aby chronić naszą aplikację, należy skupić się na opisie działania (patrz "projektowanie oprogramowania"), a nie implementacji (kod źródłowy)

Należy być czujnym i uważać na relacje z dostawcami i wykonawcami, aby zawsze mieć prawa "po swojej stronie".

Rozważam karierę rzecznika patentowego po zakończeniu studiów magisterskich.

Interesuje mnie praktycznie cały zakres nauk o zarządzaniu i jakości. Nie tylko na poziomie akademickim, ale również z poziomu prawdziwych historii przedsiębiorców i ekspertów.

Dyskusje

Rysunek. Cyfert, Szymon & Dyduch, Wojciech & Latusek, Dominika & jerzy, Niemczyk & Sopińska, Agnieszka. (2014). Subdyscypliny w naukach o zarządzaniu -logika wyodrębnienia, identyfikacja modelu koncepcyjnego oraz zawartość tematyczna. Organization and Management. 1. 37-48.