Wie kann das Änderungsmanagement für GIS-Vorgänge verwendet werden?

Ich arbeite in einer mittelgroßen Organisation, in der GIS nur ein Teil der IT-Plattform ist. Der Rest der Organisation arbeitet mit "Change Management" und möchte nun, dass wir GIS-Ingenieure besser mit Änderungsanforderungen umgehen können und so weiter.

Das Problem ist, dass wir als GIS-Administrator ständig viele Änderungen vornehmen. Starten Sie Mapservices, starten Sie sie neu, erstellen Sie neue Services, verschieben Sie Daten, aktualisieren Sie Services und Daten.

Meine Frage ist, ob jemand andere Erfahrung mit Change Management und GIS in seiner täglichen Arbeit hat und wie das für Sie funktioniert hat :)

Ich freue mich auf eine interessante Diskussion.

Dies ist ein Link, der das Change Management- Konzept erklärt .

Ich arbeite auch in einer Organisation, die den Change Management-Prozess nutzt. Für uns gilt das Änderungsmanagement nicht für tägliche Datenverwaltungsvorgänge ... das wäre überwältigend. Dies gilt im Allgemeinen für Änderungen an einem [ System / einer Datenbank ], die sich nachgeschaltet auf andere Systeme auswirken können.

Stellen Sie sich auf hoher Ebene folgende Fragen:

1. "Erwarten andere, dass [ System / Datenbank ], an dem ich arbeite, konsistent verfügbar ist?"
2. "Wird mich jemand anrufen und fragen, was mit [ System / Datenbank ] wegen der geplanten Arbeit nicht stimmt ?"
3. "Wäre es vorteilhaft, zu einem geplanten Zeitpunkt an [ System / Datenbank ] zu arbeiten, wenn jeder weiß, dass es nicht verfügbar sein wird?"

Wenn die Antwort "Ja" lautet, sollte sie wahrscheinlich Teil des Änderungsmanagements sein.

Verwenden Sie also Ihre Beispiele:

• Starten Sie Mapservices neu und ändern Sie das Management
• Services erstellen / aktualisieren = Änderungsmanagement
• Daten verschieben (vorausgesetzt, es handelt sich um einen neuen Server / eine neue Datenbank) = Änderungsmanagement
• Datenschema ändern (Name der Tabelle / Ansicht, Spalten usw.) = Änderungsverwaltung
• Daten aktualisieren = Verwaltung nicht ändern, da es unwahrscheinlich ist, dass sich jemand darum kümmert, ob FeatureID 123 oder Attribut X ausgefüllt sind. Sie müssen nur in der Lage sein, alle in der Feature-Class vorhandenen Daten zu analysieren.

Eine andere Möglichkeit, sich das wie einen Lieferservice vorzustellen: Wenn Sie an eine neue Adresse umziehen, Ihren Namen ändern und Ihre Adresse von der Gemeinde ändern lassen, sollten Sie die Post benachrichtigen. Wenn Sie ein neues Abonnement für eine Zeitschrift erhalten, muss die Bestellung dies nicht wissen, da die Lieferung nur angezeigt wird.

Der Artikel zur Änderungskontrolle ist wahrscheinlich näher an dem, woran Sie denken.

In meiner Organisation haben wir ein wöchentliches "Operations" -Treffen, bei dem wir eine Liste der bevorstehenden Änderungen durchgehen und die beteiligten Schlüsselpersonen um Statusaktualisierungen bitten und die Möglichkeit bieten, widersprüchliche Operationen zu koordinieren.

Diese Verfahren werden im Allgemeinen durch eine Standardarbeitsanweisung (SOP), eine Service Level Agreement (SLA) und / oder eine Operational Level Agreement (OLA) abgedeckt , wobei einzelne Aufgaben / Workflows in einer Wissensdatenbank (KB) dokumentiert sind . Die strategische Priorisierung großer Projekte erfolgt durch IT-Governance .

In jedem mittleren bis großen IT-Shop sollten mindestens einige dieser Standards bereits implementiert sein.

Es scheint mir, dass es beim Änderungsmanagement eher darum geht, die Struktur der Organisation oder die Anforderungen an ein Projekt zu ändern, als um die tägliche Wartung der Technologie (z. B. den Neustart von Diensten). Aus dem Abschnitt "Beispiele" des Wikipedia-Artikels, auf den Sie verlinkt haben:

Strategische Änderungen, operative Änderungen (einschließlich struktureller Änderungen), technologische Änderungen, Änderung der Einstellungen und Verhaltensweisen des Personals, Persönlichkeitsweite Änderungen

Bei einem früheren Job in einem mittelständischen Unternehmen mussten wir "Änderungskontrollen" durchführen, wenn wir Änderungen vornehmen mussten, die sich auf eine größere Produktion auswirktenIT-System oder -Komponente, wie z. B. Datenbankänderungen / -migrationen / -verbindungen, ETL-Jobs, Serverkonfigurationen usw., ohne darauf beschränkt zu sein, erforderten für Entwicklungs- und Testumgebungen keine Änderungskontrollen. Glücklicherweise hatten wir das Vertrauen unserer IT-Abteilung (verdient), sodass sie uns Freiheiten wie die vollständige Kontrolle über unsere Produktionsumgebung gaben, damit wir unsere Apps problemlos bereitstellen und bei Bedarf Änderungen vornehmen konnten. Die IT-Abteilung verfügte nicht über die Mitarbeiter, die über das Innenleben von GIS-Anwendungen Bescheid wussten, um alle täglichen Verwaltungsaufgaben zu erledigen. Das überließen sie uns. Das Bouncen von Kartendiensten erforderte für uns keine Änderungskontrolle, war jedoch in unserer SOP und unseren Dokumenten enthalten, die intern für alle verfügbar waren.

Mein Punkt: Verdienen Sie das Vertrauen Ihrer IT-Abteilung, Ihrer Datenbankadministratoren und Systemadministratoren, zeigen Sie ihnen, wie sich Ihre Verfahren auf die Systeme auswirken, und versuchen Sie nach besten Kräften, so weit wie möglich mit ihnen zusammenzuarbeiten. Versuchen Sie, eine SOP zu erstellen und zu dokumentieren, was eine Änderungskontrolle erfordert und was nicht, und halten Sie sich daran.