mboost-dp1
Flickr - Marc Bernet
Var det ikke en bedre ide at iagtage alle arbejdsgange / procedure skrive det om til en krav specifikation og lave et re-make af hele systemet i et moderne system som f.eks. Axapta eller lign. ???
Det virker en anelse omstændigt at læse gammel kode og derved måske gentage nogle fejl i det nye ?
selvfølgelig vil man derved også løbe ind i de samme 'begynderfejl' som det eksisterende program har finpudset sig ud af i løbet af årene... (man slipper dog næppe for dem alligevel)
Det virker en anelse omstændigt at læse gammel kode og derved måske gentage nogle fejl i det nye ?
selvfølgelig vil man derved også løbe ind i de samme 'begynderfejl' som det eksisterende program har finpudset sig ud af i løbet af årene... (man slipper dog næppe for dem alligevel)
Mærsk gjorde det samme for et par år siden med deres logistik, og det kostede Mærsk milliarder på bundlinjen. Spændende at se om det her bliver en ny DORA, DeMars eller tilsvarende.
#4 - Axapta... et 28 år gammelt system som har stået stille i årevis og hvor næste uprøvede udgave er forsinket flere gange. DSV er flyttet fra Skuldelev og dagene som glade amatører. De installerer hverken noget som er forældet eller uden flere servicepacks. Det bliver SAP eller Oracle.
#4 - Axapta... et 28 år gammelt system som har stået stille i årevis og hvor næste uprøvede udgave er forsinket flere gange. DSV er flyttet fra Skuldelev og dagene som glade amatører. De installerer hverken noget som er forældet eller uden flere servicepacks. Det bliver SAP eller Oracle.
Axapta kan ikke trække antallet af unikke brugere...
Måde man indfører et nyt system på er ikke nødvendigvis at lave en analyse af nuværende arbejdsgange, da disse ofte ikke er hensigtsmæssige og derfor er det MEGET dyrt at tilpasse et system til hvordan virksomheden operere. Den bedste metode er ofte at tilpasse virksomheden, da virksomheden bliver tvunget til at revurdere de gamle lig de har i lasten.
I DSVs tilfælde har de dog en størrelse der godt kan retfærdiggøre en specialudvikling, men mon ikke der findes eksisterende systemer der kan det som de reelt set har behov for. Husk altid at plejer er farlig... :)
Måde man indfører et nyt system på er ikke nødvendigvis at lave en analyse af nuværende arbejdsgange, da disse ofte ikke er hensigtsmæssige og derfor er det MEGET dyrt at tilpasse et system til hvordan virksomheden operere. Den bedste metode er ofte at tilpasse virksomheden, da virksomheden bliver tvunget til at revurdere de gamle lig de har i lasten.
I DSVs tilfælde har de dog en størrelse der godt kan retfærdiggøre en specialudvikling, men mon ikke der findes eksisterende systemer der kan det som de reelt set har behov for. Husk altid at plejer er farlig... :)
#5: Enig, Axapta er slet ikke en mulighed, jeg kunne godt forestille mig DSV gik hen og valgte SAP pga. flexibilitet (Så tilgengæld også et ret dyrt system)
Grunden til at koden skal gennemlæses er helt sikkert at der i tidernes morgen er blevet lavet specifikke løsninger baseret på de kunder som stadig benytter systemet - Som Lars Erichsen også siger, systemets force har lagt i knopskydning. For 21 år siden var der nemlig ikke industristandarder for EDI som vi kender dem i dag, og det var derfor almindelig kotume at man designede løsningen baseret på den enkelte kunde, især for de nystartede virksomheder som DSV. Jeg har selv arbejdet i FREJA Transport (dansk transportfirma, ca 600 ansatte) hvor EDI løsningerne blev konverteret til inhouse format baseret på den enkelte kunde; den maskine (En HP3000 kørende MPE XL) har kørt i 25 år og er sikkert ikke udfaset helt endnu.
Grunden til at koden skal gennemlæses er helt sikkert at der i tidernes morgen er blevet lavet specifikke løsninger baseret på de kunder som stadig benytter systemet - Som Lars Erichsen også siger, systemets force har lagt i knopskydning. For 21 år siden var der nemlig ikke industristandarder for EDI som vi kender dem i dag, og det var derfor almindelig kotume at man designede løsningen baseret på den enkelte kunde, især for de nystartede virksomheder som DSV. Jeg har selv arbejdet i FREJA Transport (dansk transportfirma, ca 600 ansatte) hvor EDI løsningerne blev konverteret til inhouse format baseret på den enkelte kunde; den maskine (En HP3000 kørende MPE XL) har kørt i 25 år og er sikkert ikke udfaset helt endnu.
Montago (4) skrev:Var det ikke en bedre ide at iagtage alle arbejdsgange / procedure skrive det om til en krav specifikation og lave et re-make af hele systemet i et moderne system som f.eks. Axapta eller lign. ???
Dansk Supermarked forsøgte sig, med det samme da de skulle flytte deres gamle butikssystem over i SAP. De ville modellere det gamle system over i SAP 1:1, de endte med at reboote deres SAP implementering efter at have brændt millioner og atter millioner af...
Det bedste og det billigste er at holde sig til de best practice setup som SAP eller Axapta er baseret på, og så forsøge at tilpasse sine processer til dette. Naturligvis mens man laver egenudvikling hvor man virkelig er helt unik...
kriss3d (1) skrev:Hvad mon det program har gjort som en god karl-koder ikke kan lave på et par måneder ?
Tror du vil blive overasket over hvor komplekst et system til transport branchen kan være, tror i hvert fald du vil kunne tjene en meget god løn hvis du kunne bygget et dedikeret program til transport virksomheder "på et par måneder"
Mange store virksomheder, der er vokset på samme måde som DSV, gør akkurat det samme.
Af samme årsag finder du stadig eksempelvis COBOL i store dele af logistik-, finans- og produktionssektoren på verdensplan. Der er ganske enkelt investeret for meget tid (og dermed penge) i løsningerne til at det er økonomisk forsvarligt at portere det hele til "moderne" systemer.
Dygtige COBOL programmører er sjovt nok i høj kurs.
Forsigtige bud fra forskellige analyseinstitutter peger på at COBOL givetvis stadig står for 70-80% af den samlede kode der driver erhvervslivet på jorden.
Mange af de største lufthavne driftes fortsat via software der har næsten 30 år på bagen. Ingen tør byde ind med noget der er bedre. Det eneste der bliver lavet om, er front-end GUI'en. Backend er stadig de gode gamle Fortran, COBOL, SNOBOL tandhjul.
Lur mig om ikke en postcentral eller 10 et sted stadig kører på Algol.
Af samme årsag finder du stadig eksempelvis COBOL i store dele af logistik-, finans- og produktionssektoren på verdensplan. Der er ganske enkelt investeret for meget tid (og dermed penge) i løsningerne til at det er økonomisk forsvarligt at portere det hele til "moderne" systemer.
Dygtige COBOL programmører er sjovt nok i høj kurs.
Forsigtige bud fra forskellige analyseinstitutter peger på at COBOL givetvis stadig står for 70-80% af den samlede kode der driver erhvervslivet på jorden.
Mange af de største lufthavne driftes fortsat via software der har næsten 30 år på bagen. Ingen tør byde ind med noget der er bedre. Det eneste der bliver lavet om, er front-end GUI'en. Backend er stadig de gode gamle Fortran, COBOL, SNOBOL tandhjul.
Lur mig om ikke en postcentral eller 10 et sted stadig kører på Algol.
nubus (5) skrev:#4 - Axapta... et 28 år gammelt system som har stået stille i årevis og hvor næste uprøvede udgave er forsinket flere gange. DSV er flyttet fra Skuldelev og dagene som glade amatører. De installerer hverken noget som er forældet eller uden flere servicepacks. Det bliver SAP eller Oracle.
Hvad fanden snakker du om ?
Jeg sidder pt med Axapta 2009 og Ax 2011 er på vej - har en ven som sidder på Microsoft og hakker løs på næste version (2011) af Axapta...
Deres seneste addon bliver til Produktionsvirksomheder...
SAP blev startet i 1972 - vil du så også påstå at SAP er 39 år gammelt ? (hvor Ax er fra 1986 = 25)
Så vidt jeg ved, så var den første offentlige release af Axapta helt fremme ved 1997-1998. Der har for det meste været 1 - 2 år imellem major releases siden da.
Så det er hverken 28 år gammel, stillestående eller uprøvet/forsinket. Det skulle da kun være i forhold til ens egen anskuelse af softwaren og de forventninger man stiller til det. Men det kan vel næppe være tilfældet på et forum hvor man jo altid er objektiv og faktuel.
Jeg har aldrig selv så meget som rørt en installationsdiskette til Axapta. Til gengæld har jeg rigelige mængder erfaringer med et andet Damgaard produkt. Nemlig Concorde C4 og C5
Så det er hverken 28 år gammel, stillestående eller uprøvet/forsinket. Det skulle da kun være i forhold til ens egen anskuelse af softwaren og de forventninger man stiller til det. Men det kan vel næppe være tilfældet på et forum hvor man jo altid er objektiv og faktuel.
Jeg har aldrig selv så meget som rørt en installationsdiskette til Axapta. Til gengæld har jeg rigelige mængder erfaringer med et andet Damgaard produkt. Nemlig Concorde C4 og C5
Problemet med Cargolink er at det er utroligt meget specialiseret til at håndtere ALLE de opgaver du smider efter den.
Nu begynder sporene af de mange år og den voksende forretning at vise sig.
Et andet problem du står overfor er hvis du køber et program som SAP og begynder at modellere det efter dit hoved så bliver det sværere at få de officielle releases som SAP kommer med, netop fordi du har gjort dit eget system til en bastard.
Nu har jeg heldigvis aldrig haft fornøjelsen af at arbejde med CL men jeg ved hvordan det ser ud og fungere.
Preach
Nu begynder sporene af de mange år og den voksende forretning at vise sig.
Et andet problem du står overfor er hvis du køber et program som SAP og begynder at modellere det efter dit hoved så bliver det sværere at få de officielle releases som SAP kommer med, netop fordi du har gjort dit eget system til en bastard.
Nu har jeg heldigvis aldrig haft fornøjelsen af at arbejde med CL men jeg ved hvordan det ser ud og fungere.
Preach
#16 -
22. mar. 2011 17:00
Montago (13) skrev:Jeg sidder pt med Axapta 2009 og Ax 2011 er på vej - har en ven som sidder på Microsoft og hakker løs på næste version (2011) af Axapta...
Hedder nu AX 2012...
Sidder med en fin AX 2012 kop som jeg fik fra tech conf....
Men hold da kæft der har været gang i produkt-holdet, godt nok kommet nogle fede features....
Vores næste planlagte projekter er AX 2012, så glæder mig som et lille barn :-P
Især til at se hvor meget den er blevet integreret med VS/.Net...
nubus (5) skrev:Spændende at se om det her bliver en ny DORA, DeMars eller tilsvarende.
Forsvaret bruger DeMars og magen til skrammel har jeg da længe set.
Montago (4) skrev:Var det ikke en bedre ide at iagtage alle arbejdsgange / procedure skrive det om til en krav specifikation og lave et re-make af hele systemet i et moderne system som f.eks. Axapta eller lign. ???
Det virker en anelse omstændigt at læse gammel kode og derved måske gentage nogle fejl i det nye ?
De skal vide præcist hvad det nye system skal gøre. I den sammenhæng er det oplagt at kigge på hvad det eksisterende system gør. Om man kigger inde fra systemet ud på brugerne eller udefra brugerne ind på systemet er vel to sider af samme sag.
nubus (5) skrev:Axapta... et 28 år gammelt system som har stået stille i årevis og hvor næste uprøvede udgave er forsinket flere gange.
Det er jo så ikke tilfældet som beskrevet i flere indlæg.
Men Dynamics AX henvender sig vist ikke til dette markedssegment.
nubus (5) skrev:De installerer hverken noget som er forældet eller uden flere servicepacks. Det bliver SAP eller Oracle.
Nu nævnes de 2 jo faktisk i artiklen, så ...
pbol01 (6) skrev:
Måde man indfører et nyt system på er ikke nødvendigvis at lave en analyse af nuværende arbejdsgange, da disse ofte ikke er hensigtsmæssige og derfor er det MEGET dyrt at tilpasse et system til hvordan virksomheden operere. Den bedste metode er ofte at tilpasse virksomheden, da virksomheden bliver tvunget til at revurdere de gamle lig de har i lasten.
I DSVs tilfælde har de dog en størrelse der godt kan retfærdiggøre en specialudvikling, men mon ikke der findes eksisterende systemer der kan det som de reelt set har behov for. Husk altid at plejer er farlig... :)
Det kan også være meget farligt at lade hvad der er nemt IT mæssigt drive forretningens processer. For at tage noget fra floskulariet: det er IT's opgave at understøtte forretningen - ikke omvendt.
#0 skrev:
De fleste programmer lever sjældent i ret mange år, inden de bliver erstattet af en nyere udgave eller et helt andet produkt.
Og det er så ikke helt rigtigt.
Plastic wrapper konsum software bliver erstattet.
For den her slags custom made business software er det helt normalt at kode lever 10-20-30 år.
Montago (13) skrev:Hvad fanden snakker du om ?
Jeg sidder pt med Axapta 2009 og Ax 2011 er på vej - har en ven som sidder på Microsoft og hakker løs på næste version (2011) af Axapta...
Deres seneste addon bliver til Produktionsvirksomheder...
Og? DSV er ikke en produktionsvirksomhed (og selv hvis de var, ville de næppe bruge version 1.0.0 af et add-on til en alfa-udgave af et system). Desuden er Ax 2011 blevet til Ax 2012 - som #16 siger og ingen bygger da en virksomhed på 30-40 mia. på et system som endnu ikke er frigivet og når det kommer vil være en blank version.
Du får hverken bestyrelse eller direktion til at gøre det. En bedre løsning er som flere siger at gå efter SAP. Det kan også salgsmodne virksomheden og gøre en fusion nemmere.
I øvrigt tror jeg MS har det fint med at være i mellemklassen.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund