Arkadiusz Figurny

Project Manager, właściciel firmy, architekt systemów

Wypowiedzi

• Wszystko
• Tylko fora

• 
  Wpis na grupie Business IT w temacie Oprogramowanie dla zakładu produkcyjnego bez FK

  4.09.2009, 10:03

  Jarek Żeliński:
  

  ROMAN WILK:
  

  Jarek Żeliński:
  
  a jak padnie ta jedna to stoi wszystko... nie generalizujmy

  No panie Jarku to już argument poniżej pasa :-))) No chyba prościej jest trzymać "mirror" jednej bazy niż kilku. Przecież dziś nikt (tak myślę) nie ryzykuje przestojów nie mając "lustra" bazy danych.

  
  :), znam fajne rozwiązania gdzie klient miał cztery apalikacje na trzech serwerach RDBMS, było to tańsze niż klaster pod bazę. Ja często liczę rentowność wdrożenia i nie zawsze najepsze jest najlepsze, wskazuje "wystarczająco dobre"...
  
  każdy prawie rolnik ma traktor na pole i osobówkę do kościoła, zakup i trzymanie terenowego autobusu z klimą nie każdemu się opłaci.
  
  proszę, nie generalizujmy, u każdego klienta siadam z biała pustą kartką i od początku kombinujemy jak to zrobić dobrze, bezpiecznie i w rozsądnych kosztach i terminie, a nie raz z czegoś się rezygnuje...

  
  Witam
  
  Może ja dodam trochę uwag z drugiej strony. Uczestniczyłem w kilku wdrożeniach jak również w towrzeniu od zera dużego systemu, a także nadzorowałem pracę kilku zależnych od siebie systemów. Zarządzanie takimi systemami jest tym trudniejsze im bardziej są one złożone.
  1. Każdy dodatkowy system powiązany z poprzednimi to dodatkowy interfejs do nadzorowania i wyjaśniania błędów (komunikacji, niezgodoności typów, niekompletnych danych itd.) Systemy różnych producentów nie są zesobą kompatybilne i niestety interfejs automatycznie wszystkiego nie załatwi.
  2. Następna kwestja to czas wymiany danych pomiedzy systemami. Pół biedy jak systemy mogą być synchronizowane raz na dobę lub na żądanie. Problemy się zaczynają gdy ten okres musi być krótki. Przy konfigurowaniu interfejsu trzeba wtedy barć pod uwagę opóźnienia w poszczególnych etapach wymiany danych. Dodatkowo przy dużej ilości danych i mało optymalnych systemach może się okazać że czas potrzebny na synchronizację jest tak duży że dezorganizuje pracę działu lub działów które korzystają z systemów.
  3. Dalej jeżeli mamy kilka systemów zlinkowanych z jednym centralnym systemem to może się okazać że awaria jednego z systemów składowych przed zsynchronizowaniem się danych powoduje blokadę lub nie spójność danych w głównym systemie.
  4. Jeżeli chodzi o aktualizację jednego z systemów to w takim przypadku powinno się testować wszystkie systemy z nim związane.
  5. Utrzymywanie każdej dodatkowej bazy i serwera to dodatkowa praca dla administratorów.
  6. Dobrze jeżeli każdy z systemów ma swój system testowy (nawet jeżeli jest to system stowrzony przez dużą firmę programistyczną) i każde nowe uaktalnienie jest najpierw testowane w takim systemie testowym, w którym do testów każdorazowo bierze się pełne zrzut danych produkcyjnych. Miałem już przypadki gdzie wykrywaliśmy błedy w gotowych nowych paczkach wgranych w środowisku testowym i dzięki temu nie zatrzymywaliśmy systemu produkcyjnego.
  
  Wynika z tego że im mniej systemów tym lepiej i według mnie jeżeli jest system który w dużym stopniu obejmie procesy w firmie to lepiej wziąść gotowy system i dobudować do niego kilka dodatkowych modułów/ systemów tworzonych na zamówienie lub stworzyć nowy system dedykowany od zera.
  Jeżeli chodzi o bezpieczeństwo i wydatki z tym związane to o kosztach możemy się przekonać dopiero jak mamy problemy ze spójnością lub odzyskaniem danych. Koszty przestoju systemu i odzyskania danych mogą być nawet wyższe niż koszty zakupu systemu. Wybór zawsze należy do klienta.

• 
  Wpis na grupie Lean Management w temacie Sekwencyjne przygotowanie opakowań dla linii produkcyjnych.

  6.08.2009, 10:40

  Witam
  
  Uczestniczę obecnie w pracach nad elektronicznym systemem nadzoru transportu pustych opakowań i wyrobu w obszarze produkcji. Jeżeli jest Pan zainteresowany to proszę o kontakt na priv.

• 
  Wpis na grupie Business IT w temacie Produkt czy usługa?

  3.02.2009, 00:16

  Według ITILa V3 ogólna definicja usługi określa ją jako środek dostarczania wartości klientom poprzez umożliwienie im realizacji wyników, bez konieczności posiadania przez nich specyficznych rodzajów ryzyka lub kosztów. W skład usługi wchodzi miedzy innymi oprogramowanie, sprzęt i praca ludzi, którzy tą usługę wspierają.

• 
  Wpis na grupie Lean Management w temacie system wymiany informacji przy tablicach

  2.02.2009, 10:11

  Może warto pomyśleć o wersji elektronicznej?