[Gelöst] CC/RTC: Zertifizierung

Hallo.

Habe mal eine Logikfrage.

Ich arbeite bei einem Endkunden welcher mit einem Vertragspartner zusammen arbeitet. Wir führen seit 2 Jahren ein ERP ein, wo noch ein zusätzliches Modul integiert wird.
Ich persönlich habe bisher in der Anwendungsentwicklung gearbeitet und habe die Anpassungen vom Vertragspartner koordiniert und kleinere Anpassungen selbst durchgeführt. Jetzt ist uns von unseren Teamleiter und Abteilungsleiter, welche nichts im ERP zu tun haben und auch das System nicht kennen, verboten worden, selber im ERP zu entwickeln, also wir dürfen noch nicht mal eine Caption von irgendeinen Feld ändern, wenn intern der Bedarf besteht. Andererseits, sollen wir aber die Objekte und den Code bewerten, welcher von unseren Vertragspartner geliefert wird, bevor er in unser Produktivsystem importiert wird. Die wollen jetzt plötzlich alle Changes beim Vertragspartner beauftragen.
Angeblicher Grund hierfür ist, dass unser ERP angeblich zertifiziert werden soll, jetzt plötzlich.
Im Moment führe ich nur Korrekturen von falschen Datenbeständen durch und entwickle nicht mehr.

Das ergibt für mich so richtig keinen Sinn, wie seht ihr das?

VG
Chris

Zuletzt geändert von navCH am 20. Januar 2016 12:21, insgesamt 3-mal geändert.

wenn die bei euch eingesetzte Lösung dann eine Branchenlösung werden soll, dann macht es natürlich Sinn.
Wenn Ihr gleichzeitig Änderungen an den Objekte vornehmt und diese Änderungen dann nicht den Zertifzizerungsregeln
entsprechen, dann ist keinem geholfen.

Wenn Ihr gleichzeitig Änderungen an den Objekte vornehmt und diese Änderungen dann nicht den Zertifzizerungsregeln

Aber seit wann findet die Zertifizierung kundenseitig statt?
Ist es nicht normalerweise so, dass der Partner seine (originäre) Branchenlösung zur Zertifizierung einreicht, und dann eine bestimmte Anzahl von Kunden nur bestätigen müssen, dass sie mit dieser arbeiten?

Für mich klingt das so, als würde der Partner diesmal gar keine eigene Entwicklungsdatenbank vorhalten, sondern alles beim Kunden entwickeln und von dort aus zur Zertifizierung einreichen.

@sweikelt:

es handelt sich um keine Branchenlösung, sondern ist eine nur auf uns zugeschnittene individuelle Anpassung, oder soll es werden!

Ich kann mir hier drei Ursachen vorstellen, die dafür sprechen, dass alle Entwicklungen ausschließlich durch den Microsoft Partner durchgeführt werden sollen:

1. Ihr befindet euch in einem validierten Umfeld.
2. Ihr seid das Pilot-Projekt für die Entwicklung einer Branchen- bzw. Spezial-Lösung des Partners.
3. Fehlerbehebungen durch den Partner, die ihr selber verursacht habt, werden abgerechnet, wohingegen Fehlerbehebungen, die der Partner verursacht hat, i. d. R. kostenlos sind.
   (Sofern der Software-Mangel innerhalb der Gewährleistungsfrist (lt. AGB des Partners) dem Partner mitgeteilt wurde.)

Für mich klingt das so, als würde der Partner diesmal gar keine eigene Entwicklungsdatenbank vorhalten, sondern alles beim Kunden entwickeln und von dort aus zur Zertifizierung einreichen.

Der Vertragspartner entwickelt auf eigener DB.
Aussage von meinem Abteilungsleiter war, das eine Prüfungskommision, einer übergeorneten Organsisation, diese Zertifizierung von unserer Software einfordern könnte.
Zu unserer betrieblichen Struktur möchte ich nicht so viel schreiben.

Hallo,

Die NAV- Buchhaltung ist von einem Wirtschaftsprüfungsunternehmen auf korrekte Abläufe geprüft worden. dafür gibt es in Deutschland ein Testat. Dies ist die Basis für viele Wirtschaftsprüfer, die Buchhaltung anzuerkennen.
Wenn Ihr jetzt in NAV selbst programmiert, könnt ihr diese korrekten testierten Abläufe durcheinander bringen.
Dabei hängt es von eurer Lizenz ab, ob ihr das könntet. Die Möglichkeit Objekte zu verändern gibt es in drei Zugriffsebenen, dem Table, Form u. Reportdesigner (mit dem darf man mehr oder weniger nur Kästchen schieben, oder neue Felder hinzufügen, aber außer in Reports eigentlich nicht programmieren), dem Application- Developer (der darf eigentlich (fast) alles programmieren, das nicht buchhaltungsrelevante Daten verändert) und dem Solutiondeveloper (der darf eigentlich alles bearbeiten, auch die Buchhaltung)
Wenn ihr letzteres in eurer Kundenlizenz habt, könntet ihr theoretisch und auch praktisch eure Buchhaltung manipulieren. Ihr, als Firma, seit damit auch selbst für die Korrektheit eurer Daten verantwortlich.

Wenn das der Hintergrund des Verbotes ist, genügt es allerdings nicht das Verbot auszusprechen, die entsprechende Granule muss auch aus eurer Lizenz entfernt werden.

Gruß, Fiddi

Ich kann mir hier drei Ursachen vorstellen, die dafür sprechen, dass alle Entwicklungen ausschließlich durch den Microsoft Partner durchgeführt werden sollen:

1. Ihr befindet euch in einem validierten Umfeld.
2. Ihr seid das Pilot-Projekt für die Entwicklung einer Branchen- bzw. Spezial-Lösung des Partners.
3. Fehlerbehebungen durch den Partner, die ihr selber verursacht habt, werden abgerechnet, wohingegen Fehlerbehebungen, die der Partner verursacht hat, i. d. R. kostenlos sind.
   (Sofern der Software-Mangel innerhalb der Gewährleistungsfrist (lt. AGB des Partners) dem Partner mitgeteilt wurde.)

Zu 1.) Von valdierten Umfeld kann keine Rede sein. Die gepflegten Daten sind seinem Verwendungszweck noch nicht vollständig angemessen! Eine teilweise Validierung sollte noch nachbearbeitet werden.

Zu 2.) Speziallösung ja. Pilotprojekt fraglich. Aber könnte theoretisch sein. Allerdings gibt der Vertragspartner, seit den letzten zwei Jahren keine Richtlinien zur gemeinsamen Entwicklung vor, sondern hat parallel mit uns entwickelt.

Zu 3.) kommt nicht in Betracht.

Solutiondeveloper (der darf eigentlich alles bearbeiten, auch die Buchhaltung)
Wenn ihr letzteres in eurer Kundenlizenz habt, könntet ihr theoretisch und auch praktisch eure Buchhaltung manipulieren. Ihr, als Firma, seit damit auch selbst für die Korrektheit eurer Daten verantwortlich.

Wenn das der Hintergrund des Verbotes ist, genügt es allerdings nicht das Verbot auszusprechen, die entsprechende Granule muss auch aus eurer Lizenz entfernt werden.

Gruß, Fiddi

@Fiddi
Ja, aber den Solution Developer bezahlen (die ja nicht ganz billig ist) und dann ein Verbot zu bekommen nichts mehr im System zu ändern, wäre dann wohl echt übertrieben.

@navCH Wenn du als Admin angestellt bist, kannst du dich ja dann zurücklehnen und diese zertifizierte Lösung administrieren und dann alles auf deinen MS-Partner schieben. Zumindestens in der Theorie.

mfg,
winfy

Ja, aber den Solution Developer bezahlen (die ja nicht ganz billig ist) und dann ein Verbot zu bekommen nichts mehr im System zu ändern, wäre dann wohl echt übertrieben.

Über die Konsequenzen des Solution- Developers denken viele aber im ersten Moment nicht nach, oder werden auch nicht darauf hingewiesen.

Gruß Fiddi

Wenn Ihr gleichzeitig Änderungen an den Objekte vornehmt und diese Änderungen dann nicht den Zertifzizerungsregeln

Aber seit wann findet die Zertifizierung kundenseitig statt?
Ist es nicht normalerweise so, dass der Partner seine (originäre) Branchenlösung zur Zertifizierung einreicht, und dann eine bestimmte Anzahl von Kunden nur bestätigen müssen, dass sie mit dieser arbeiten?

Für mich klingt das so, als würde der Partner diesmal gar keine eigene Entwicklungsdatenbank vorhalten, sondern alles beim Kunden entwickeln und von dort aus zur Zertifizierung einreichen.

ich meinte, dass es möglich sei, dass ihre derzeitige Lösung vom Partner in Absprache mit deren Geschäftsführung wohl zu einer Branchenlösung (wie timo schrieb: "Pilotprojekt") werden kann
und deshalb das Verbot der Anpassung ausgesprochen wurde

Hallo,

@Christian: Klingt für mich nach politischen Spannungen. Ungeplantes Projektende oder so. Die Ausrede ist wenig glaubhaft... auch wenn das gleichzeitige entwickeln des Kunden und des Partners nicht so einfach zu koordinieren ist, kriegt man das für gewöhnlich hin. Die Testatkeule schwingt man gern, solange aber die Entwickler des Kunden selber die SolDev-Zertifizierung haben (oder zumindest einer) und die Firma Due Diligence nachweisen kann, zieht das nicht. Ich kenne diese "Ihr macht garnix, wir geben alles nach aussen" Vorgehensweise nur von Situationen wo man sich streitet und etwas erzwingen will... wie z.B. Verzug oder Mängelrüge. Wenn es aber soweit ist, ist für gewöhnlich die Erkenntnis gereift das das Endprodukt nicht sichtbar und/oder nicht brauchbar ist.

LG Jens

Die Testatkeule schwingt man gern, solange aber die Entwickler des Kunden selber die SolDev-Zertifizierung haben (oder zumindest einer) und die Firma Due Diligence nachweisen kann, zieht das nicht. Ich kenne diese "Ihr macht garnix, wir geben alles nach aussen" Vorgehensweise nur von Situationen wo man sich streitet und etwas erzwingen will... wie z.B. Verzug oder Mängelrüge. Wenn es aber soweit ist, ist für gewöhnlich die Erkenntnis gereift das das Endprodukt nicht sichtbar und/oder nicht brauchbar ist.
LG Jens

Bei uns als Endkunden besitzt keiner eine SolDev-Zertifizierung.
Eine Due Diligence könnte sein, mit dem Ziel für oder gegen das Produkt.

Aber ich vermute das da noch eine weitere Möglichkeit eine Rolle spielt, und zwar ist meiner Ansicht nach, bei einem Teil der Teamleitung, nicht der Wille vorhanden, das System zum Erfolg zu führen. Es mögen mehrere Gründe dafür verantwortlich sein, aber zwei Gründe könnten sein,

1. da es sich um einen externen Dienstleister handelt und bei diesem keine Motivation vorhanden ist, dass künftige System zu Supporten und in das zu betreuende AD mit zu integrieren, da es sich um eine Belastungsprobe handeln könnte.

2. Persönliche Interessen.

Das klingt für euch sicherlich sehr chaotisch.

VG

Klingt als solltest Du mal Stellenanzeigen studieren. Nur für den Fall.

Das klingt für euch sicherlich sehr chaotisch.
VG

ja

ich verstehe nicht ganz, was euer Entwicklungsverbot mit dem Erfolg bzw. laut deiner Aussage Misserfolg des Projektes zu tun hat?

... die einen machen nix und die anderen dürfen nix machen... klingt offensichtlich...

Das klingt für euch sicherlich sehr chaotisch.
VG

ja

ich verstehe nicht ganz, was euer Entwicklungsverbot mit dem Erfolg bzw. laut deiner Aussage Misserfolg des Projektes zu tun hat?

z.B.

1. Entwicklungsverbot bedeutet auch zeitliche Verzögerungen beim Anpassungsprozess

2. Entwicklungsverbot bedeutet Einfluss der bisherigen Koordination (mir) in den Entwicklungsprozess

3. Entwicklungsverbot könnte meiner Meinung nach den jenigen in Karten spielen, die dem System kritisch gegenüber stehen

Muss ehrlich gestehen, dass ich nicht wirklich weiß was ich von dieser Situation halten soll, deswegen kreisen meine Gedanken.
Reaktionen in meinem Umfeld stützen diese Theorie.

Klingt als solltest Du mal Stellenanzeigen studieren. Nur für den Fall.

möchte ich eigentlich im Moment nicht, obwohl die Lage gut aussehen würde

Ist sowieso immer alles anders.

MfG

möchte ich eigentlich im Moment nicht, obwohl die Lage gut aussehen würde

Wieso nicht? Nigel Frank und Elliot Browne haben sicherlich was passendes für dich.
Egal bei welchem NAV-Partner in CH du momentan schaust, alle suchen einen NAV-Entwickler.
Warum musst du leiden, weil irgendwann fremde Interessen deine Abteilung oder evtl. die ganze Firma gegen die Wand fahren lassen?