Bangun matriks RACI Tinjau SoW Buat bagan organisasi tim dan daftar kontak Buat model keterlibatan dengan tim cloud internal Anda Dokumentasikan proses pembuatan dan penerapan cloud Peta jalan proyek dan pelacak tonggak sejarah

Praktik terbaik untuk tahap perencanaan

Selama fase perencanaan implementasi SAP greenfield, proyek biasanya menghadapi berbagai tantangan dan peluang. Bagian ini membahas lima pembelajaran utama berdasarkan SAP pada implementasi AWS greenfield yang telah dilibatkan oleh tim Layanan AWS Profesional. Anda dapat menerapkan beberapa rekomendasi ini bahkan sebelum proyek Anda dimulai atau tim konsultan terlibat. Menyediakan draf dokumen seperti matriks peran dan tanggung jawab atau daftar kontak tim membantu mempercepat proses ramp-up.

Bangun matriks RACI

Membangun matriks penugasan tanggung jawab untuk tim infrastruktur sangat penting untuk setiap proyek implementasi. Matriks ini mengambil bentuk bagan yang bertanggung jawab, akuntabel, dikonsultasikan, dan diinformasikan (RACI) yang komprehensif. RACI digunakan untuk mengklarifikasi peran, tugas, dan tugas dalam struktur tim yang kompleks. Ini harus dikembangkan dalam kemitraan dengan tim AWS SAP Cloud, tim SAP Basis, SAP Systems Integrator (SI), dan pelanggan. Ini dapat didorong oleh salah satu kelompok tersebut atau oleh manajer proyek. Membangun RACI tanpa masukan dari para pemangku kepentingan ini menciptakan inkonsistensi, kesenjangan, dan kadang-kadang bahkan konflik. Penting untuk mempertimbangkan semua fase proyek. Memiliki RACI di muka memperkuat kemitraan di antara semua pihak yang terlibat dan menciptakan kejelasan. Idealnya, RACI harus diselesaikan sebelum proyek dimulai.

Berikut adalah kutipan dari matriks RACI sampel untuk proyek implementasi SAP greenfield.

Unduh matriks RACI lengkap

Matriks RACI untuk SAP pada proyek AWS greenfield.

Tinjau SoW

Memahami semua elemen pernyataan kerja (SoW) untuk layanan AWS konsultasi dan konsultasi, dan bersama-sama meninjau SoW dengan pemangku kepentingan utama sehingga hasil dapat dipahami dengan jelas oleh semua. Jika tim infrastruktur bermaksud untuk melakukan lebih dari apa yang didefinisikan oleh SoW, pastikan untuk mendokumentasikannya dalam log risiko, asumsi, tindakan, masalah, dependensi, dan keputusan (RAAIDD). Dalam proyek implementasi SAP greenfield, tetap gesit dan gesit adalah yang paling penting, jadi menyimpang dari SoW adalah skenario umum. Namun, harapan dapat dikaburkan jika mitra AWS implementasi mulai memberikan melampaui apa yang didokumentasikan. Ketika perubahan terjadi, Anda harus menyimpan daftar lingkup pekerjaan baru dan trade-off yang mungkin harus dilakukan. Untuk pendekatan proyek air terjun, proses manajemen perubahan ruang lingkup harus didefinisikan dan diimplementasikan. Untuk proyek tangkas, proses prioritas backlog lebih tepat untuk mengelola ruang lingkup.

Pertimbangan:

Saat Anda maju melalui proyek, pastikan untuk menangkap ruang lingkup baru dan menentukan kiriman baru. Ini akan membantu Anda mengelola harapan dan mencari bantuan dalam memprioritaskan backlog Anda.
Identifikasi dan prioritaskan perubahan dokumentasi dan tugas bersama dengan backlog pengiriman yang ada, sehingga dokumentasi dapat diproduksi sepanjang masa proyek alih-alih ditunda hingga akhir.
Lakukan penelusuran SoW reguler di seluruh proyek agar tetap selaras dengan kiriman dan prioritas.
Untuk pemotongan produksi, pastikan untuk memiliki SoW dengan akses hanya-baca yang disetujui setidaknya 12 bulan sebelumnya untuk membantu dengan dukungan hypercare.

Buat bagan organisasi tim dan daftar kontak

Bangun bagan organisasi tingkat tinggi yang menggambarkan tim dan struktur kepemimpinan. Pergi lebih dalam dengan mengembangkan daftar kontak lintas tim yang mencakup nama, judul, dan peran semua orang di tim infrastruktur dan titik kontak utama untuk berbagai fungsi, seperti keamanan, operasi jaringan dan firewall, Microsoft Active Directory, operasi cloud in-house, dan operasi server. Setiap orang harus tahu siapa yang terlibat dan peran apa yang mereka mainkan dalam proyek tersebut. Keterlambatan dan miskomunikasi pasti terjadi ketika tim tidak memiliki informasi ini. Memahami judul para pemangku kepentingan juga penting. Misalnya, Anda tidak ingin mengundang pemangku kepentingan tingkat direktur untuk sesi desain kerja atau stand-up harian, kecuali mereka adalah kontributor utama diskusi. Mengetahui judul dan peran memungkinkan Anda mengundang orang yang tepat ke pertemuan yang relevan. Mampu memvisualisasikan tim dalam bagan organisasi membantu Anda memahami bagaimana tim terstruktur dan bekerja sama dalam proyek.

Diagram berikut memberikan contoh SAP khas pada bagan organisasi AWS infrastruktur.

Contoh SAP pada bagan organisasi AWS infrastruktur.

Buat model keterlibatan dengan tim cloud internal Anda

Jika organisasi TI Anda memiliki tim AWS Cloud internal, Anda harus membuat model keterlibatan dengan tim tersebut dan mengklarifikasi pekerjaan yang akan mereka lakukan, dibandingkan dengan apa yang ditugaskan oleh mitra AWS implementasi (misalnya, Layanan AWS Profesional atau AWS Mitra). Tanggung jawab utama yang perlu dipertimbangkan adalah dukungan lingkungan setelah mereka dibangun dan diserahkan. Misalnya, jika hanya ada dua arsitek AWS SAP Cloud yang membangun infrastruktur multi-lanskap dan multi-lingkungan untuk selusin aplikasi SAP, mereka tidak akan memiliki bandwidth untuk mendukung lingkungan yang mereka selesaikan membangun dan membangun lingkungan baru pada saat yang sama. Salah satu opsi adalah meminta tim cloud internal untuk mengambil alih dukungan dari lingkungan yang telah selesai. Ini memberi tim in-house kesempatan untuk belajar dan mengambil kepemilikan lingkungan. Mereka pada akhirnya akan bertanggung jawab untuk memelihara dan memperluas lingkungan ini, ketika proyek berlangsung dan ruang lingkup pekerjaan baru diidentifikasi.

Infrastruktur cloud internal dan DevOps tim cloud juga harus menyetujui jenis perangkat lunak otomatisasi yang akan digunakan—misalnya, apakah akan menggunakan AWS CloudFormation atau Terraform sebagai alat infrastruktur sebagai kode (IAc). Demikian pula, mereka mungkin memutuskan untuk menggunakan AWS Systems Manager atau Ansible untuk tugas-tugas konfigurasi seperti volume bootstrap dan mungkin instalasi SAP. Keputusan ini harus didokumentasikan. Selain itu, jika ada persyaratan untuk dasbor pemantauan dan observabilitas pihak ketiga, tetapi ini bukan kiriman di SoW, pertimbangkan untuk menempatkan kait pemantauan dan pencatatan dengan menggunakan Amazon dan Amazon Simple Notification Service ( CloudWatch Amazon SNS) untuk sementara. Tim cloud internal dapat menerapkan integrasi dengan solusi pemantauan pihak ketiga di lain waktu.

Model keterlibatan atau perjanjian dukungan juga harus menjadi bagian dari matriks RACI dan diartikulasikan dalam SoW. Ada tingkat otomatisasi yang signifikan yang dapat dicapai dengan menggunakan AWS layanan. Matriks SoW dan RACI harus mengidentifikasi apa yang perlu dicapai sebagai bagian dari proyek implementasi SAP greenfield, dan apa yang dapat didelegasikan ke tim operasi.

Saat Anda membuat model keterlibatan, tentukan apakah pendekatan air terjun, gesit, atau campuran akan menjadi metode kunci untuk bergerak maju. AWS Layanan Profesional mengamati peningkatan 300 persen dalam penyelesaian tugas dan pengurangan 94 persen dalam waktu perencanaan dalam keterlibatan yang menerapkan pendekatan gesit atau campuran dibandingkan dengan pendekatan air terjun. Pada tahap perencanaan, Anda juga harus memilih rencana komunikasi dan pendekatan perkakas dengan bantuan pelanggan. Tabel berikut menunjukkan contoh rencana komunikasi.

Contoh rencana komunikasi untuk SAP pada proyek AWS greenfield.

Terakhir, pastikan untuk mengidentifikasi pelanggan dan tim SAP Basis yang akan mendukung proyek lebih awal. Melatih mereka saat Anda menerapkan dan memigrasikan solusi baru adalah kunci untuk memulai sesi transfer pengetahuan lebih awal.

Dokumentasikan proses pembuatan dan penerapan cloud

Jika organisasi TI Anda memiliki tim cloud internal, tim tersebut harus mendokumentasikan proses pembuatan dan penerapan cloud dengan menggunakan diagram alur proses dan membagikan diagram ini dengan seluruh tim. Anda ingin pemangku kepentingan utama Anda untuk dengan mudah mendeteksi setiap kemacetan atau inefisiensi dalam proses, dan memahami peran yang dimainkan proses internal Anda yang ada dalam menciptakan inefisiensi atau penundaan. Dalam contoh berikut, Anda dapat melihat bagaimana proses pembaruan Active Directory bergabung dan Domain Name System (DNS) membutuhkan waktu paling lama untuk diselesaikan. Memiliki visual ini dapat memotivasi tim untuk berkolaborasi dan mencari cara untuk mengurangi waktu yang terlibat dalam langkah proses itu.

Contoh diagram alur proses untuk pembuatan cloud dan proses penerapan SAP pada AWS implementasi greenfield

Pertimbangan:

Dokumentasikan proses help desk dan alur kerja secara terpisah, bagikan informasi ini dengan tim infrastruktur, dan pastikan setiap orang memiliki akses ke alat help desk sehingga tidak ada ketergantungan pada satu orang. Seringkali, mungkin ada proses tiket yang rumit dan memakan waktu untuk melakukan bergabung Active Directory, pembaruan DNS, membuka firewall, dan meminta kunci enkripsi. Sangat penting untuk mendokumentasikan proses ini dan mempertimbangkan Perjanjian Tingkat Layanan (SLA) dari setiap tim dalam tahap perencanaan proyek. Ini juga membantu menjelaskan alasan penundaan atau kemacetan yang membutuhkan perhatian khusus untuk menghilangkannya.
Tetapkan titik kontak bernama untuk Active Directory dan firewall atau tugas jaringan. Sumber daya khusus tersebut harus menjadi bagian dari proyek Anda. Jika Anda harus mengandalkan tiket layanan, Anda tidak dapat mengontrol layanan SLA.