Thời gian qua mình có viết khá nhiều bài chia sẻ về cách học, cách tiếp cận SAP, một số con đường để trở thành SAP Consultant chuyên nghiệp. Sau đó nhận được rất nhiều câu hỏi inbox riêng tư tâm sự tỉ tê với nhau rằng là mai mốt ra trường, để làm SAP Consultant giỏi thì cần rèn luyện những kỹ năng mềm hay các kiến thức chuyên ngành như thế nào.
Lộ trình tự tìm kiếm kiến thức chuyên sâu hơn về hệ thống SAP thì đã có chia sẻ ở những bài viết hướng dẫn trước đó:
Đây là một bài viết khá dài dòng và cơ bản theo ý kiến chủ quan nhưng cũng có thể là dịp để mình nhìn lại bản thân có những kỹ năng đó hay chưa để biết mà còn có thể trui rèn những điểm còn hạn chế. Mọi người đọc bài này với tâm thế cùng nhau vui vẻ nhé. Bài viết này có tham khảo từ quyển BABOK của dân làm BA - Các bạn có thể tìm đọc thêm nhé.
I/ Đầu tiên là nhóm kỹ năng về tư duy phân tích - Analytical Thinking.
Mình không giỏi phần này nhưng sau khi tìm hiểu và liên hệ lại thì thấy mục đích sau cùng của nhóm kỹ năng này là chúng ta có thể hiểu được những thứ mình phân tích, hiểu được bản chất của vấn đề. Khi đó chúng ta định hướng được cho các hành động tiếp theo phù hợp hơn, hiệu quả hơn với vấn đề mà chúng ta đang gặp phải.
Trong nhóm skill này sẽ có 5 phần để hình thành tư duy phân tích:
1/ Conceptual và Visual Thinking
Hiểu đơn giản, đây là hai góc nhìn theo hướng trừu tượng và trực quan.
Khi bạn bắt đầu nghề tư vấn về ERP hay SAP, đây là các sản phẩm không thể cầm nắm được. Nên khi làm việc với khách hàng giai đoạn ban đầu họ đang tìm hiểu, chúng ta cứ nói về concept chung của giải pháp thì dễ gây bối rối cho khách hàng ở nhóm người sử dụng. Họ đâu có hình dung được nó là cái gì, khi mọi thứ vẫn còn chung chung và trừu tượng quá.
Khi đó, việc nhìn thấy giao diện phần mềm, một vài chức năng cơ bản sẵn có sẽ khiến khách hàng dễ hình dung hệ thống được sử dụng trong tương lai hơn rất nhiều => đó là Visual.
Visual Thinking là kỹ năng mình nghĩ sẽ rất cần phát triển khi trở thành SAP Consultant vì sẽ có rất nhiều thứ rất khó hình dung rõ vấn đề. Đặc biệt là các vấn đề liên quan đến chuyên môn.
Ví dụ: đối với nhóm Consultant triển khai dự án đã được chia làm 2 nhóm: SAP Functional Consultant và SAP Technical Consultant (bên dưới còn chia nhánh chi tiết hơn cho từng vị trí nữa). Làm thế nào để một bạn chuyên ngành kinh tế hiểu được những thứ từ bạn Technical như API, Web Portal,.. hay là nhận và gửi data giữa các third party theo luồng nào, các solution đó ảnh hưởng đến perfomrnance ra sao,... và ngược lại...
Đội SAP Consultant thường chia thành Functional and Technical
Khi đó hãy nhớ đến Visual Thinking. Vẽ lại những thứ chúng ta nói, vẽ lại những thứ chúng ta cần, vẽ lại luồng thông tin chúng ta suy nghĩ cho người khác hiểu. Khi mọi thứ được phác thảo rõ ràng ra bằng hình ảnh, bản chất vấn đề sẽ dần lộ diện.
Cái khó là vẽ như thế nào để dễ hiểu, để hiệu quả => chúng ta cần học và tích lũy rất nhiều qua thực tế
Khi những thứ quá trừu tượng và khó hiểu, mình mới dùng tới Visual Thinking nhưng ngược lại, có những giai đoạn chúng ta lại dùng Conceptual Thinking.
Ví dụ trong giai đoạn sales và pre-sales, nhà cung cấp thường hay cần trình bày bức tranh chung của giải pháp mà mình đề xuất cho BOD của khách hàng. Khi trình bày high-level thì góc nhìn của họ rất bao quát và trừu tượng. Họ luôn nhìn bài toán tổng thể từ trên cao mà ít khi quan tâm đến chi tiết bên trong có gì. Và họ rất hiểu những khái niệm trừu tượng mà chúng ta nói ra.
Thực tế mình thấy Conceptual Thinking và Visual Thinking thường cần phải đi chung với nhau và bổ trợ cho nhau. Đội Sales và Presales nắm bắt được tổng quát thì cần về trao đổi trong team các phần chi tiết của dự án với team Consultant. Trong quá trình triển khai dự án, team Functional cần nắm các concept tổng quan và viết FS detail cho team Technical hiểu được các yêu cầu đặc tả của dự án…
2/ Creative & Innovative
Các bạn có để ý thấy trong công việc hằng ngày, mọi người hay share nhau các tool mới, các tool hay dùng để làm việc nhanh hơn, hiệu quả hơn, thuận tiện hơn,... thì theo mình đó là cách sáng tạo trong công việc để làm việc tốt hơn, hiểu quả hơn.
Nhiều lúc overload với task nên mình cũng thử nhiều cách khác nhau rồi bí ý tưởng thì hay quan sát và copy mấy cái người khác làm mà mình thấy hay hay rồi về vận dụng thử coi coi tốt hơn không thì theo mình đó cũng là sáng tạo và đột phá rồi (creative & innovative)
3/ Problem Solving
Đối với kỹ năng về giải quyết vấn đề, mình thấy ai cũng cần kỹ năng này hết. Kỹ năng này cần xuyên suốt mọi lúc từ khi chưa có dự án tới lúc làm dự án rồi tới lúc đóng dự án thì vẫn còn 1 đống vấn đề cần giải quyết.
Và hầu như không có công thức chung cho hoàn cảnh cụ thể. Cái này tùy lúc và tùy người mà có cách giải quyết khác nhau. Có những vấn đề rất bé, cũng có những vấn đề rất phức tạp, có những vấn đề rất gấp và có những vấn đề rất mông lung. Nhiệm vụ của mình là cần bình tĩnh lại, xác định vấn đề đang gặp là gì. Một khi đã hiểu vấn đề, chúng ta mới nghĩ đến phương án giải quyết.
Thực tế mình nghĩ rèn được kỹ năng này cũng khó, vì rất nhiều lúc chúng ta gặp những thứ không phải là chuyên môn, hoặc vấn đề có quá nhiều thông tin chồng chéo nhau và có nhiều người, khi gặp vấn đề đó là cứ phang vào mình mà nói, đủ thứ búa lua xua trên trời dưới đất. Rồi khách hàng làm khó, team nội bộ mâu thuẫn không thống nhất,... Khi đó việc của bản thân mình chỉ là bình tĩnh và cố gắng tỉnh táo, quan sát xem xem đâu là vấn đề cốt yếu, nó thuộc khía cạnh nào, lĩnh vực nào, có liên quan đến mình hay không, liên quan nhiều hay ít,...
...và khi là người đầu mối thông tin, 99% bạn sẽ là người phải can thiệp các vấn đề đó.
Nếu chưa có kinh nghiệm thì đi hỏi, quan sát xem leader mình giải quyết như thế nào, khi đó học cách giải quyết.
4/ Decision Making
Thường mọi người khi làm các dự án ERP hay SAP thường gặp rất nhiều tình huống kiểu khách hàng cứ nhờ support miết, mà hợp đồng thì đã đóng rồi, lâu lâu lại call nhờ hỗ trợ,...
Nếu xét về lý, thì team Consultant không cần support gì cả. Còn nếu muốn raise ticket để support thì đợi khách hàng ký hợp đồng maintenance.
Nếu xét về tình, thì team sales thường hay năn nỉ, không thể nói không support được. Khách hàng thì cứ hứa tháng sau anh trình lên sếp duyệt dự án -> Sales thì cố gắng giữ mối quan hệ cho sau này.
Nếu chưa dám ra quyết định thì các bạn cứ trao đổi với leader của mình xem xét giải quyết. Quyết định nào cũng đều có hai mặt - lợi và hại. Tùy thuộc vào mình => kỹ năng ra quyết định hình thành ở chổ này. Sau dự án, mọi người có happy với nhau hay không là ở giai đoạn này. Cả về internal lẫn external.
Thông thường đội technical hay consultant thì không thích ưỡm ờ, 1 là một mà 2 là hai. Fixed scope rồi thì cứ thế mà làm, muốn thay đổi thì làm change request, cứ dựa vào đó mà tính tiền.
Còn đội sales thì thấy nhiều phần yêu cầu support nó nhỏ xíu, nên cứ hứa rồi nhờ các team khác hỗ trợ để rồi bị leader đội kia complain với leader của mình rồi bị la hoài.
Sau này mình học được cách linh động hơn ví dụ như là khéo léo đặt deadline cho những case như vậy. Kiểu như: "Dạ anh ơi, cái này để em hỏi thử consultant bên em làm có tốn time nhiều không, với lại hôm trước em nghe mấy bạn report với sếp em là dự án đã đóng rồi. Giờ mấy bạn support hoài thì không biết khai timesheet vô đâu á. Nên bên anh cố gắng coi mình còn phần nào cần support trong 2 tuần tới thì nói em để em báo các bạn support xong cho mình luôn nha. Chứ sau đó nữa thì em sợ khó á,..."
Đây chỉ là một cách tham khảo để mình dung hòa mối quan hệ và lợi ích của 2 bên. Thỏa thuận này chỉ có hiệu lực trong một khoảng thời gian nhất định, chứ không thể kéo dài vô thời hạn. Chúng ta cần đặt ra một giới hạn và thông báo cho khách hàng về những gì có thể đạt được trong thời gian này. Sau thời gian đó, mọi thứ cần phải trở nên rõ ràng minh bạch.
Khi vào dự án sẽ có rất nhiều trường hợp mà chúng ta cần phải ra quyết định dù nhỏ hay lớn. Chưa biết thì nhờ hướng dẫn là các anh chị có kinh nghiệm hơn. Họ hướng dẫn nhiều quá và quên thì lấy viết ra noted lại, lấy điện thoại ra ghi âm lại (mình đang làm),... xem xem tại sao các anh chị đó lại làm như vậy rồi học từ từ.
Problem Solving (giải quyết vấn đề) thì luôn đi kèm với Decision Making (kỹ năng ra quyết định). Còn việc ra quyết định thì luôn đi kèm với hai chữ “trách nhiệm”. Đừng để người khác phải mất nhiều thời gian và công sức hơn cho những quyết định của mình nhưng không mang lại được điều gì.
Tư duy hệ thống là khi chúng ta có khả năng hiểu và đánh giá vấn đề từ một góc nhìn toàn diện. Khi gặp phải vấn đề, kỹ năng này sẽ giúp chúng ta tự động nhận ra những yếu tố bên trong hoặc liên quan có thể bị ảnh hưởng. Từ đó, các bạn có thể quyết định bước tiếp theo một cách hợp lý.
Ví dụ đối với một quy trình Lead-to-Cash trong SAP vẽ ra như thế này, bên dưới đó là các sản phẩm tương ứng đề xuất nếu cần. Nhưng khách hàng nói KHÔNG. Hiện tại bên tui đã có cái hệ thống này (A), hệ thống này (B), và hệ thống này (C) đang chạy rồi. Bây giờ không muốn thay thế nó.
Nếu không có tư duy hệ thống, các bạn sẽ rất mịt mờ, và thường không có khuynh hướng cân nhắc xem thử: thay thế phần bên ngoài vào vào thì nó sẽ ảnh hưởng gì tới những thành phần còn lại.
Và thường hay gặp là các yêu cầu từ A đến D phải thông qua B và C nhưng sau vài tháng, khách hàng không muốn có B và thay C bằng C'. Đây là việc chúng ta sẽ gặp rất thường xuyên với bất kỳ change request nào, dù to hay nhỏ. Nếu chưa đánh giá vấn đề một cách toàn diện và chưa nhận ra những khía cạnh hoặc yếu tố khác có thể bị ảnh hưởng, team mình rất dễ gặp phải rủi ro hoặc bị kẹt trong tình huống khó khăn.
Do đó, những người có tư duy hệ thống sẽ có khuynh hướng phân tích điều này một cách tự nhiên, đầy đủ và rõ ràng hơn bao giờ hết. Và quan trọng trên hết, chúng ta cần trang bị đủ kiến thức + nhiều kinh nghiệm thực tế thì mới có được một góc nhìn bao quát và đầy đủ nhất được.
Các bạn có thể nhớ rằng stakeholders chỉ quan tâm: có vấn đề mới nảy sinh đó, giờ team Consultant bên đó trả lời như vầy, team nó xử lý như vầy => rồi kết qua đem lại có đáp ứng đúng kỳ vọng các bên hay không? => Người ta chỉ quan tâm kết quả sau cùng mà thôi. Nên chuyện tư duy có tổng quát hay không không ai kiểm chứng được ngay, mà người ta chỉ dựa vào kết quả làm được.
Thế nên trước khi confirm bất cứ thứ gì đến khách hàng, bạn cần phải trao đổi mọi thứ thật kỹ và rõ ràng với team nội bộ.
Trong các cuộc họp các các bên đó thì đừng có ngồi im im. Bạn hãy phản hồi cho mọi người biết và hiểu các bạn đang nghĩ gì về vấn đề đó dù câu hỏi hay ý kiến có stupid cỡ nào đi nữa cũng được, ai cũng cần phải học mà đúng không. Khi đó mọi người sẽ xem xét góc nhìn hay ý kiến bạn đưa ra đã bao quát hay chưa, có phiến diện quá hay không.
II/ Tiếp theo là đến kỹ năng giao tiếp - Communication
Mình không giỏi nhóm kỹ năng cái này, nên cũng không biết bắt đầu từ đâu nhưng cơ bản chúng ta cần phải giao tiếp rất nhiều từ trong công việc đến bên ngoài cuộc sống... mình từng giao tiếp rất kém và cũng đang giao tiếp rất kém, bạn bè hay dùng từ là "đâm xuồng bể" để trêu ghẹo mỗi khi mình tham gia vào một cuộc nói chuyện nào đó. Ngôn ngữ cơ thể của mình cũng không tự tin,...
Chỉ sợ bản thân mình không biết những thứ mà mình không biết. Còn khi đã tự nhận thức được những điểm yếu kém của bản thân thì sẽ cần học và tìm cách khắc phục, không đc 10 điểm thì cũng phải ráng lết lên 6-7 điểm chứ đúng không!!!
Giao tiếp bằng lời nói tưởng dễ mà khó. Thực tế chúng ta cần sử dụng kỹ năng này rất nhiều.
- Bạn nói không ai hiểu -> mọi người lơ lơ, ưỡm ờ.
- Trao đổi nội bộ, nói 1 ý diễn tả lại tám ngàn lần vẫn chưa hiểu -> quá mất thời gian
- Văn ngôn ẩn dụ, nói ít hiểu nhiều -> người ta hiểu sai -> giận hờn không nhìn mặt nhau...
- Đi lấy requirements, không control được buổi workshop -> lệch agenda buổi họp -> tèo luôn buổi workshop.
- ....
Giai đoạn đầu với nghề ERP này, mình khá nhút nhát trong công việc. Các bạn có thể hình dung, sinh viên mới ra trường, 22-23 tuổi, kiến thức chuyên môn không có, giao tiếp không tốt, chọn hướng làm sales B2B. Khi gọi lấy requirements hay gặp và trao đổi với các anh chị lớn hơn nhiều, họ là expert trong công việc họ làm => mức độ tự tin của mình hoàn toàn bị dập tắt và độ tự ti về các khuyết điểm của bản thân dâng cao,...
Khi đó mình chọn cách đi theo các leader thật nhiểu buổi họp nhất có thể, các anh chị đó hỏi câu hỏi gì, đặt vấn đề ra sao,... mình sẽ ghi âm và noted lại các câu hỏi thường xuyên được hỏi nhất. Trong các buổi họp sau đó, chính bản thân mình phải "tự cạy được miệng của mình ra" và hỏi đúng câu hỏi đã nhớ trước đó. Dần dần thành quen, từ ngồi im thin thít, mình đã có thể mở miệng hỏi được một đến hai câu hỏi rồi,...
Và mình nghĩ, chúng ta hãy nên tranh thủ thuyết trình, tranh thủ nói, tranh thủ trình bày, nói chuyện trước đám đông. Khi đó bạn sẽ nhận được rất nhiều phản hồi => bạn rèn được cách đỡ đòn cho các câu hỏi xoáy, cách phản hồi cho các tình huống khó, cách suy nghĩ nhanh và logic hơn, cách giải quyết vấn đề tốt hơn,...)
Nói tốt thì cần đi kèm nghe tốt, nghe ẩu là dễ dính đòn ngay. Nhiều thứ nhìn qua tưởng đơn giản, nhưng nếu không chú ý lắng nghe, có thể thành một mớ rối rắm khó gỡ, thậm chí mất nhiều connection, mất nhiều cơ hội trong tương lai.
Có một lần, cách đây nhiều năm, như thường lệ, cứ nghe keyword là "bên anh đang có nhu cầu SAP", mình liền set up meeting và dẫn đội xuống và gặp BOD của khách hàng mà không lấy requirements thêm và anh contact point bên khách hàng cũng tin tưởng mình. Đến nơi mới vỡ lẽ, dịch vụ mình cung cấp không có cái nào khớp với yêu cầu bên khách hàng đó. Cuộc họp sượn trân đó chỉ diễn ra 15p, nhưng 20 con người di chuyển hơn 60p chỉ để gặp nhau, chào nhau 1 cái,....và không có sau đó nữa.
Từ đó, nguyên tắc là cứ phải xác nhận lại những gì mình nghe để đảm bảo rằng mình nghe đúng những gì đối tác hay khách hàng mình diễn giải.
3/ Body Language
Làm Consultant, chúng ta sẽ có nhiều cơ hội gặp được khách hàng hay đối tác nên ngôn ngữ cơ thể dễ gây ấn tượng ban đầu với khách hàng.
Cái này thì chắc cần phải tập luyện nhiều, để ý và tập nhiều để có thể hình thành thói quen. Có thể là khi sinh ra đã có thần thái đó, hoặc là do môi trường xung quanh tác động.
Mỗi sáng đi làm, có phải bạn quan sát thấy có những người vui tươi đầy năng lượng hoặc có những người, đi tới đâu là tối thui tới đó, nhìn nó cứ bèo nhèo sao đó.
Vì sao? Vì nó nằm ở cách đi đứng của mình, tư thế lưng có thẳng, có tự tin hay không. Ngồi làm việc cổ có gục xuống không, lưng có khòm hay không. Nhiều lúc những thứ nhỏ nhỏ như cử chỉ cũng ảnh hưởng nhiều đến tinh thần làm việc của mọi người xung quanh. Không những thế, cái tiêu cực nó cũng rất dễ lây lan.
Có một giai đoạn mình quyết định chuyển đổi công việc khi nhận lời góp ý từ đồng nghiệp rằng: "Sao em nhìn anh thấy tồi tàn hơn hồi xưa nhiều, 1 phần vibe của anh hong có thần thái tự tin nữa, người mới gặp dễ có cảm giác đó,..."
Đó, ngôn ngữ cơ thể, có thể bạn không nhận ra nhưng người khác nhìn vào sẽ thấy.
Kỹ năng viết là một skill mà mình nghĩ rằng khá thực tế và dùng hằng ngày.
Bạn làm hợp đồng, làm báo giá, làm user manual, viết test case, viết mail, viết tài liệu đặc tả (fs), viết note trong buổi họp, viết mail xin tăng lương, mail xin nghỉ việc,... đều cần phải viết.
Viết sao cho hay, sao cho ngắn gọn, súc tích, sao cho trịnh trọng, viết sao cho logic, viết sao cho dễ hiểu,...đều cần rèn luyện.
Với blog này, đây là một kênh để mình tập viết, và khi viết mình phát hiện ra vài điều quan trọng:
-
Khi bạn nói, bạn sẽ không có thời gian nhiều như khi viết. Bạn có thời gian để suy nghĩ, để học cách trau chuốt câu từ, có thời gian để suy nghĩ sao cho gọn,... nói chung khi viết được tốt, kỹ năng nói cũng sẽ được phát triển theo từ từ vì đã dành thời gian mài giũa câu từ khi viết, nên viết nhiều sẽ tạo thói quen. Đến khi nói, các bạn sẽ tự nhiên sử dụng những câu chữ đã được trau chuốt từ trước mà không cần suy nghĩ nhiều..
-
Khi bạn viết lại những gì được nghe, được học, bạn sẽ nhớ lâu hơn rất nhiều so với chỉ nghe các kiến thức đó. Nó giống như một dạng thực hành vậy.
III/ Business Knowledge
Đây làm nhóm kỹ năng mình nghĩ là bắt buộc cần có đối với người làm Consultant. Thực tế khi có kiến thức liên quan đến các quy trình nghiệp vụ của khách hàng, bạn sẽ có thể dễ trao đổi, tư vấn và tìm giải pháp để giải quyết các bài toán khách hàng đưa ra.
1/ Industry Knowledge
Sẽ ra sao khi có anh Giám đốc tài chính hay chị Kế toán trưởng nào chịu ngồi trao đổi giải pháp cho phòng kế toán khi bạn không nắm được các khái niệm hay nguyên lý căn bản trong lĩnh vực của họ như General Ledger, Trial Balance, Chart of Account,...
Hay có anh IT Manager nào chịu nghe bạn đề xuất các giải pháp hạ tầng khi không biết dự án triển khai on-premise, on-cloud, public cloud, private cloud,... là như thế nào không?
Hay có anh Quản lý sản xuất nào nghe bạn tư vấn mà BOM hay BOM đa cấp mà bạn cũng không biết là gì hay không??
Ban đầu, đó chỉ là yêu cầu cơ bản thôi. Quan trọng hơn, khách hàng luôn mong muốn mình đóng vai trò tư vấn cho họ. Để làm được điều đó, chúng ta cần phải có kinh nghiệm thực tế, chứ không thể chỉ nói suông mà chưa từng làm qua. Chém gió mà không có thực lực thì khó mà thuyết phục được ai.
Rất nhiều khách hàng sẽ hỏi về kinh nghiệm triển khai của đơn vị tư vấn. Nếu chưa có kinh nghiệm ngành dọc, hãy thật lòng chia sẻ đừng chém gió vì trước mặt các bạn sẽ là toàn expert. Bạn có thể hình dung rằng: "Bạn đang đi tư vấn cho những công ty đầu ngành trong chính lĩnh vực của họ." Chỉ cần chém bậy 1-2 câu là toang.
Ví dụ SAP sẽ có BEST PRACTICE cho từng Industry. Một bạn SAP Consultant chuyên về Retails thì không chắc rằng bạn sẽ chuyên về sản xuất. Nếu chỉ làm cho sản xuất mà áp dụng vô tội vạ những đặc thù đó cho bán lẻ, giáo dục, thương mại, y tế,... mà không chịu research trước thì rất nguy hiểm.
Thực tế là trên thế giới có hàng trăm ngành nghề, và có lẽ chúng ta chỉ thành thạo được một hoặc một vài lĩnh vực nhất định. Vì vậy, việc rèn luyện chuyên môn thật vững và liên tục cập nhật những xu hướng mới là con đường an toàn hơn để phát triển.
Sẽ có thêm Industry Knowledge hay kiến thức ngành mà chúng ta cần phải tìm hiểu ví dụ như: những best practice thường áp dụng trong ngành đó là gì, các điểm khó khăn và những pain point lớn nhất mà mọi người phải đối mặt. Hiểu rõ các quy định trong ngành đó và nắm vững quy trình nghiệp vụ cơ bản là điều bắt buộc.
Ví dụ, khi gặp khách hàng trong ngành F&B tại Việt Nam, chúng ta mới hiểu rõ được một vài pain point của họ như là cần tính chính xác COGS (giá vốn hàng bán) cho từng món ăn trong mỗi set menu. Điều này đòi hỏi phải phân rã từng thành phần nguyên liệu trong món ăn rồi tổng hợp lại cho toàn bộ set menu. Khi có thông tin đó, khách hàng mới có thể điều chỉnh giá bán một cách phù hợp theo từng thời điểm trong năm. Hay việc quản lý hao hụt nguyên vật liệu tươi sống,...
Tuy nhiên, các bạn đừng quá lo lắng vì có kinh nghiệm trong ngành chưa hẳn đã là lợi thế, còn chưa có kinh nghiệm không có nghĩa là bất lợi. Đôi khi, khi hoàn toàn mới mẻ với ngành, chúng ta lại có những góc nhìn đơn giản nhưng đúng bản chất của vấn đề. Đôi khi những câu hỏi có vẻ hơi stupid mà chúng ta đặt ra có thể giúp khách hàng làm rõ bức tranh của họ một cách rõ ràng, có nghĩa và chân thật hơn bao giờ hết.
2/ Learning Something New
Có thể khẳng định, ERP hay SAP Consultant sẽ luôn tiếp cận với rất nhiều khách hàng thuộc nhiều lĩnh vực, nhiều vị trí trong suốt sự nghiệp. Do đó kỹ năng có thể tự học được nhiều điều mới thực chất vô cùng quan trọng.
Thực tế là khách hàng không có thời gian chờ đợi để mình phải trở thành chuyên gia trong một lĩnh vực nào đó mới tiếp tục làm việc với mình. Và mình cũng không thể có quá nhiều thời gian chuẩn bị đủ để master mọi thứ mà khách hàng cần. Vì thế, khả năng tìm hiểu và học hỏi nhanh là vô cùng quan trọng với những người làm trong linh vực này. Và khi đã tiếp xúc và làm việc đủ nhiều trong một số lĩnh vực và ngành nghề, việc quyết định dừng lại và tập trung chuyên môn sâu vào một lĩnh vực cụ thể là hoàn toàn nằm ở quyết định của chính mỗi bản thân chúng ta.
3/ Solution Knowledge
Đây là nhóm kiến thức về giải pháp mặc dù đến khoảng thời gian gần đây mình mới hình dung rõ ràng hơn để chia sẻ cùng mọi người.
Chúng ta không thể nào đi bán ERP cho một khách hàng chỉ muốn sử dụng CRM. Kiểu chúng ta cần gãi đúng chổ ngứa cho khách hàng giữa hàng ngàn giải pháp ngoài kia.
Giải pháp có thể là ERP, CRM, DMS, HRM, POS, MES, e-Commerce, Loyalty Management, Smart Living, Smart Transportation, TMS… và ít nhất chúng ta phải có kiến thức về nó. Không chỉ dừng lại ở việc biết, mà còn phải tận dụng được kinh nghiệm đã từng triển khai giải pháp ở các dự án trước. Điều này giúp mình áp dụng vào dự án mới một cách hiệu quả hơn. Ví dụ sẽ có đối tác chuyên làm các dự án SAP cho ngành Retails, cũng có đối tác chuyên làm SAP cho sản xuất mặc dù họ cùng triển khai cùng 1 sản phẩm là SAP.
Điều này cho thấy rõ ràng: Điều quan trọng là làm sao để kinh nghiệm của mình tăng lên qua từng năm, chứ không phải chỉ là con số thâm niên 5 năm hay 10 năm. Kinh nghiệm là những gì chúng ta rút ra, tích lũy được trong suốt quãng thời gian làm việc. Còn thâm niên chỉ là số năm hành nghề, chỉ là những con số khô khan nếu kinh nghiệm vẫn dậm chân tại chỗ. Nếu bạn đã làm 5 dự án với 5 giải pháp y hệt nhau mà không rút ra được gì, không làm giải pháp trở nên hiệu quả hơn, thì rõ ràng bạn đang thiếu kiến thức cập nhật mới về giải pháp và xu thế.
Bên cạnh đó còn có khá nhiều các kỹ năng khác mà mình cũng muốn nói thêm như teamwork, teaching, presentation, đàm phám, tự học, khả năng thích nghi, pitching, effective management, time management, hay cả kỹ năng tự bán mình... nhưng bài viết đã khá dài, hẹn gặp lại mọi người trong một bài chia sẻ khác.
P/s: Bài viết này dựa trên góc độ quan sát và suy nghĩ thiển cận riêng của người viết hi vọng có thêm một ít đóng góp cho các bạn đang vào nghề. Mọi người có thể đóng góp hay bàn luận thêm bên dưới nhé.