Quy trình quản lý văn bản đi

Một phần của tài liệu (LUẬN văn THẠC sĩ) ứng dụng kiến trúc chính phủ điện tử và mô hình SAAS (software as a service) cho các dịch vụ phần mềm cấp phường,xã (Trang 53)

CHƯƠNG 1 MỞ ĐẦU

4.1. Phân tích nghiệp vụ

4.1.3. Quy trình quản lý văn bản đi

4.1.3.1. Mô hình quy trình nghiệp vụ

Hình 4.2: Quy trình nghiệp vụ xử lý văn bản đi 4.1.3.2. Mô tả các bước trong quy trình

 Đăng ký phát hành văn bản đi - Đối tượng thực hiện: Nhân viên - Đầu vào: N/A

- Đầu ra: Tạo ra văn bản dự thảo, trình lãnh đạo phê duyệt - Mô tả: Thông tin văn bản dự thảo gồm có:

o Thông tin văn bản đi dự thảo

o Loại văn bản (*): Là 1 danh mục chỉ rõ văn bản này thuộc thể loại nào. Ví dụ như là công văn, chỉ thị, tờ trình, thông báo…

o Thời hạn trình: mặc định là 15 ngày sau thời gian trình (tạo văn bản)

o Độ mật (*): Là một danh mục có sẵn, thiết lập theo hệ thống hoặc có thể thêm nếu cần. Bao gồm các mức: Tuyệt mật, Tối mật, Mật, Bình thường. Mặc định là Bình thường

o Độ khẩn (*): Là một danh mục có sẵn, thiết lập theo hệ thống hoặc có thể thêm nếu cần. Bao gồm các mức: Thượng khẩn, Khẩn, Hỏa tốc, Bình thường. Mặc định là Bình thường

o Trích yếu (*): Nhập thông tin trích yếu của văn bản, thông tin này chỉ ra văn bản này được ban hành nhằm mục đích gì.

o Ý kiến xử lý: Ý kiến của người trình văn bản

o Đính kèm file (*): Người dùng chọn từ file mềm lưu tại máy tính để tải lên hệ thống

o Người duyệt văn bản (*): là lãnh đạo của phòng ban nơi chuyên viên làm việc

o Người ký văn bản (*): là lãnh đạo được cấp quyền ký văn bản đi của tổ chức/doanh nghiệp

o Nơi nhận văn bản: nơi nhận nội bộ, nơi nhận bên ngoài

 Để xử lý

 Để báo cáo

Lưu ý:

- Khi lãnh đạo phòng ban là người đăng ký, thì có thể phê duyệt trực tiếp tại màn hình đăng kí mà không cần chọn người duyệt, chỉ cần chọn người ký

- Ký tự * thể hiện thông tin yêu cầu bắt buộc có.

 Phê duyệt văn bản

- Đối tượng thực hiện: Lãnh đạo phòng ban - Đầu vào: Văn bản trình ký

- Đầu ra: Văn bản được duyệt

- Mô tả: Thông tin duyệt văn bản gồm

o Ý kiến phản hồi (*):

o File đính kèm: attach file đính kèm

o Phê duyệt: có phê duyệt hay không?

Khi lãnh đạo phê duyệt là điều kiện cần để văn bản chuyển tới người ký. Điều kiện đủ là tất cả người duyệt văn bản đều PHÊ DUYỆT văn bản thì văn bản mới được chuyển tới người ký

Khi duyệt văn bản, người duyệt có thể thực hiện các luồng phụ sau:

o Yêu cầu đơn vị phối hợp:

 Ký văn bản

- Đối tượng thực hiện: Lãnh đạo đơn vị - Đầu vào:

- Văn bản dự thảo trình ký đã được tất cả các Người duyệt ký thông qua - Đầu ra: Văn bản đã được duyệt, hoặc văn bản chưa được duyệt

- Mô tả: Thông tin gồm có

o Ý kiến phê duyệt (*)

o File đính kèm:

o Phê duyệt: có phê duyệt hay không?

Khi lãnh đạo phê duyệt, thì văn bản được ký và chuyển tới văn thư để vào sổ phát hành

 Vào sổ ban hành văn bản

- Đối tượng thực hiện: Văn thư đơn vị

- Đầu vào: Văn bản dự thảo đã được ký thông qua bởi Người ký - Đầu ra:

o Văn bản đi được vào sổ ban hành

o Văn bản được chuyển tới danh sách văn bản đi - Mô tả: Thông tin vào sổ ban hành văn bản gồm:

o Sổ văn bản (*): Sổ văn bản đi, do văn thư định nghĩa

o Số đi (*): Số trong sổ văn bản đến của đơn vị

o Loại văn bản (*): Là 1 danh mục chỉ rõ văn bản này thuộc thể loại nào. Ví dụ như là công văn, chỉ thị, tờ trình, thông báo…

o Số hiệu văn bản (*): nhập theo thông tin ghi trên văn bản. Ví dụ 10/CT- VTQD.

o Ngày đến (*): ngày đơn vị nhận được văn bản

o Ngày ban hành (*): Là ngày ghi trên văn bản

o Độ mật (*): Là một danh mục có sẵn, thiết lập theo hệ thống hoặc có thể thêm nếu cần. Bao gồm các mức: Tuyệt mật, Tối mật, Mật, Bình thường. Mặc định là Bình thường

o Độ khẩn (*): Là một danh mục có sẵn, thiết lập theo hệ thống hoặc có thể thêm nếu cần. Bao gồm các mức: Thượng khẩn, Khẩn, Hỏa tốc, Bình thường. Mặc định là Bình thường

o Hạn giải quyết: Mặc định là ngày hiện tại. Là thời hạn mà phải xử lý văn bản.

o Trích yếu (*): Nhập thông tin trích yếu của văn bản, thông tin này chỉ ra văn bản này được ban hành nhằm mục đích gì.

o Ghi chú: Nhập thông tin ghi chú của văn bản, là thông tin bổ sung của văn bản

o Đính kèm file (*): Người dùng chọn từ file mềm lưu tại máy tính để tải lên hệ thống

o Nơi lưu (nơi soạn thảo)

o Nơi nhận văn bản: nơi nhận nội bộ, nơi nhận bên ngoài. Với nơi nhận nội bộ chỉ rõ

 Để thực hiện

 Để báo cáo

 Xem để biết

Lưu ý:

- Các thông tin đã nhập khi Đăng kí phát hành văn bản là các thông tin mặc định, văn thư có thể sửa trên những thông tin này

- Ký tự * thể hiện thông tin yêu cầu bắt buộc có.

 Gửi văn bản đi

- Đối tượng thực hiện: Văn thư đơn vị

- Đầu vào: Văn bản đã được vào sổ ban hành

- Đầu ra: Văn bản được chuyển tới đúng nơi nhận để thực hiện/báo cáo - Mô tả: Văn bản được chuyển tới nơi nhận để xử lý hoặc báo cáo 4.1.4. Các module chức năng hệ thống

Hệ thống cần phải có các khối chức năng chính sau đây: - Quản lý văn bản đến

- Quản lý văn bản đi - Quản lý Lịch làm việc

- Quản lý Thư viện văn bản pháp quy - Quản lý Thư viện biểu mẫu hành chính - Quản lý Thông báo, danh bạ

- Quản lý danh mục dữ liệu

4.2. Thiết kế hệ thống 4.2.1. Mô hình tổng thể chức năng hệ thống 4.2.1. Mô hình tổng thể chức năng hệ thống HỆ THỐNG QUẢN LÝ VĂN BẢN CẤP XÃ Quản lý văn bản đến Quản lý văn bản đi Quản lý Lịch làm việc Quản lý Thông báo, danh bạ Quản lý Thư viện văn bản pháp quy Quản lý Thư viện biểu mẫu

hành chính Văn thư Người dùng Lãnh đạo đơn vị Quản lý danh mục dữ liệu Quản trị hệ thống Hình 4.3: Mô hình tổng thể chức năng hệ thống 4.2.2. Mô hình phân rã chức năng

Hình 4.5: Mô hình phân rã chức năng Quản lý văn bản đi

Hình 4.6: Mô hình phân rã chức năng Quản lý lịch làm việc

Hình 4.8: Mô hình phân rã chức năng Quản lý biểu mẫu hành chính

4.3. Thiết kế cơ sở dữ liệu

4.3.1. Thiết kế bảng cơ sở dữ liệu

Hệ thống được thiết kế gồm các bảng sau:

STT Tên bảng Ghi chú

1 Doc_DocumentIn Văn bản đến

2 Doc_DocumentDirection Ý kiến chỉ đạo văn bản

3 Doc_DocumentInSendHistory Lịch sử gửi văn bản

4 Doc_DocumentInUserView Văn bản đến theo người dùng

5 Doc_Book Sổ văn bản

6 Doc_DocumentStatus Trạng thái văn bản

7 Doc_DocumentLog Lịch sử luân chuyển văn bản đến

8 Doc_DocumentOut Văn bản đi

9 Doc_DocOutReceive Đối tượng nhận văn bản nội bộ

10 Doc_DocOutAgencyReceive Đơn vị bên ngoài nhận văn bản đi

11 Calendar Lịch làm việc

12 Doc_Library Thư viện văn bản

13 Notice Thông báo

14 DM_Agency Danh mục cơ quan gửi bên ngoài

15 DM_DocumentField Danh mục lĩnh vực văn bản

16 DM_DocumentType Danh mục loại văn bản

17 DM_DocumentCategory Danh mục chuyên mục văn bản

19 DM_LevelSecurity Danh mục độ khẩn

20 DM_Position Danh mục chức vụ

21 DM_Priority Danh mục độ ưu tiên

22 HR_Department Danh mục phòng ban, đơn vị

23 HR_Employee Danh mục người dùng

24 HR_Group Danh mục nhóm người dùng

25 SYS_ActionLog Nhật ký hệ thống

26 SYS_LoginLog Nhật ký đăng nhập

27 SYS_Menu Menu chức năng

28 SYS_Permission Danh mục quyền cơ bản

29 SYS_Role Dannh mục vai trò

30 SYS_UserRole Người dung theo vai trò

31 SYS_UserMenu Menu người dùng

4.3.2. Mô hình thực thể liên kết 4.3.2.1. Quản lý văn bản đến 4.3.2.1. Quản lý văn bản đến

4.3.2.2. Quản lý văn bản đi

Hình 4.10: Sơ đồ thực thể liên kết chức năng Quản lý văn bản đi do văn thư phát hành

4.4. Xây dựng chương trình thử nghiệm 4.4.1. Môi trường cài đặt, triển khai 4.4.1. Môi trường cài đặt, triển khai

Ứng dụng quản lý văn bản được xây dựng và triển khai trên nền tảng công nghệ Microsoft Azure, cụ thể các công nghệ và môi trường cài đặt như sau:

- Hệ điều hành: Windows Azure - Hệ quản trị CSDL: SQL Azure.

- Công nghệ lập trình ứng dụng Web: .NET, Jquery, HTML5, XML, CSS, EXT.NET.

- Nền tảng công nghệ: .NET. - Máy chủ web: IIS.

- Giao thức: HTTP.

- Công cụ lập trình: Visual Studio 2010, Windows Azure SDK for .NET, Windows Azure Emulators

4.4.2. Các bước triển khai ứng dụng lên Window azure 4.4.2.1. Bước 1- Tạo ứng dụng trên window azure 4.4.2.1. Bước 1- Tạo ứng dụng trên window azure

Hình 4.11: Khởi tạo ứng dụng trên window azure

4.4.2.2. Bước 2 - Tải Publish Profile của ứng dụng

4.4.2.3. Bước 3 - Deploy ứng dụng lên window azure

Hình 4.13: Deploy ứng dụng lên window azure – bước 1

Hình 4.15: Deploy ứng dụng lên window azure – bước 3

4.4.3. Màn hình giao diện 4.4.3.1. Giao diện trang chủ 4.4.3.1. Giao diện trang chủ

Hình 4.17: Giao diện trang chủ hệ thống quản lý văn bản Cấp Phường/Xã

4.4.3.2. Giao diện quản lý văn bản đến

4.4.3.3. Giao diện thêm mới văn bản đến

Hình 4.19: Giao diện thêm mới văn bản đến

4.4.3.4. Giao diện quản lý lịch làm việc

4.4.3.5. Giao diện giám sát ứng dụng

CHƯƠNG 5. PHÂN TÍCH KẾT QUẢ 5.1. Kết quả đạt được 5.1. Kết quả đạt được

Về mặt lý thuyết luận văn tập trung cho 3 vấn đề sau: - Lý thuyết cơ bản về Kiến trúc Chính phủ điện tử. - Lý thuyết về phần mềm hoạt động theo mô hình SaaS. - Nắm được nghiệp vụ chính quyền cấp Phường/Xã

5.1.1. Lý thuyết về Kiến trúc Chính phủ điện tử và mô hình SaaS

Thông qua luận văn, đã làm sáng tỏ được các khái niệm cơ bản các thuật ngữ liên quan như: Kiến trúc tổng thể, Kiến trúc nghiệp vụ, Kiến trúc thông tin, Kiến trúc giải pháp, Kiến trúc công nghệ... Phương pháp phát triển kiến trúc Chính phủ điện tử theo Togaf, Zachman, ITI-GAF.

Luận văn đã nêu lên tình hình phát triển của Chính phủ điển tử ở Việt Nam cũng như trên thế giới, qua đó chỉ rõ những mặt tích cực và hạn chế, những ảnh hưởng của Chính phủ điện tử đối với sự phát triển chung của xã hội.

Luận văn đã đưa ra cái nhìn cơ bản về ứng dụng dạng SaaS, hiểu được ứng dụng SaaS là như thế nào, có khác biệt gì so với các ứng dụng phần mềm được phát triển

theo mô hình truyền thống.

5.1.2. Xây dựng kiến trúc chính phủ cấp Phường/Xã

Luận văn đã chỉ ra phương pháp và xây dựng kiến trúc chính phủ điện tử, đã mở ra được cách làm cho sự phát triển của chính phủ điện tử cấp Phường/Xã.

Với việc nghiệp vụ cấp Phường/Xã là như nhau trên toàn quốc, việc ứng dụng công nghệ SaaS để xây dựng hệ thống ứng dụng tập trung trong phạm vi 1 tỉnh để triển khai cho toàn bộ các Phường, Xã, Thị trấn, giúp tiết kiệm về mặt đầu tư hạ tầng tài nguyên và đầu tư phát triển nâng cấp ứng dụng. Việc quản lý, vận hành tập trung giúp tiết kiệm chi phí vận hành và đặc biệt là cơ sở để hình thành chính quyền điện tử liên thông toàn tỉnh.

5.2. Đánh giá lợi ích, ưu điểm của phương pháp luận

Phương pháp luận kiến trúc cho phép ta xây dựng một kiến trúc toàn diện gồm nghiệp vụ, dữ liệu, ứng dụng, công nghệ và an toàn an ninh.

Phương pháp luận kiến trúc là chuẩn của cơ quan, tổ chức, doanh nghiệp sử dụng như một công cụ để tạo ra sự thống nhất và nhất quán trong cách hiểu cũng như chỉ đạo điều hành và thực hiện việc ứng dụng CNTT, cũng như việc phối hợp, kết hợp các hoạt động giữa các đơn vị trong tổ chức.

5.3. Bài học rút ra khi áp dụng phương pháp luận vào bài toán thực tế

Từ những kết quả tìm hiểu về một số phương pháp luận xây dựng kiến trúc Tổng thể cũng như áp dụng kiến trúc ITI-GAF, một số kinh nghiệm được rút ra như sau:

- Để cơ quan, tổ chức, doanh nghiệp phát triển ổn định và vững chắc, rất cần thiết phải xây dựng kiến trúc tổng thể. Kiến trúc tổng thể có thể coi như tấm bản đồ dẫn tới thành công cho cơ quan, tổ chức, doanh nghiệp đó.

- Kiến trúc tổng thể sẽ bao gồm tổng hợp tất cả các tài liệu mô tả về toàn cơ quan và mô tả lộ trình ứng dụng CNTT để nâng cao hiệu quả hoạt động nhằm đạt được các mục tiêu và chiến lược của mình.

- Kiến trúc Tổng thể phân định rõ ràng các miền hoạt động của tổ chức, tách bạch và làm rõ các mối quan hệ giữa các hoạt động nghiệp vụ và hoạt động kỹ thuật. Đây là cơ sở cho việc nâng cao nhận thức về tầm quan trọng của các thành phần trong toàn tổ chức. Từ đó giúp cho việc hỗ trợ các nghiệp vụ tốt hơn cũng như là cơ sở đề xuất các chiến lược kinh doanh mới từ hạ tầng kỹ thuật hiện có.

- Cần phải có lộ trình thực hiện kiến trúc tổng thể. Để đi được tới đích, kiến trúc tổng thể sẽ phải trải qua các giai đoạn phát triển khác nhau với các tùy chỉnh theo từng thời kỳ cho phù hợp với các điều kiện thực tế thời điểm đó.

- Khi áp dụng phương pháp luận kiến trúc vào thực tế việc đầu tiên là phải nắm rõ phương pháp luận và biết cách vận dụng một cách linh hoạt phù hợp với bài toán cụ thể chứ không thể áp đặt. Biết cách lựa chọn các phương pháp và các hướng dẫn phù hợp chứ không nhất thiết phải áp dụng một cách cứng nhắc. Việc thứ hai là phải nắm rõ bài toán thực tế, nắm rõ các yêu cầu, xác định rõ phạm vi và mục tiêu của bài toán.

5.4. Các vấn đề còn tồn tại

- Tôi nhận định đây là 1 đề tài khó, bởi khối lượng kiến thức cần tìm hiểu là rất nhiều, do thời gian thực hiện luận văn còn hạn chế nên tôi chưa thể nghiên cứu sâu một số nội dung quan trọng khác của khung kiến trúc TOGAF như: Một số hướng dẫn trong các kỹ thuật; Kho tư liệu kiến trúc và giải pháp của tổ chức; Khung năng lực kiến trúc. Do đó kết quả ứng dụng vào bài toán thực tế chưa được toàn diện và chưa được tối ưu về mọi mặt.

- Trong thực tiễn, Chính phủ điện tử cấp Phường/Xã là 1 vấn đề khó bởi quy mô bài toán, nghiệp vụ cấp Phường/Xã là rất lớn. Đồng thời để xây dựng thành công chính phủ điện tử cấp Phường/Xã cần có nhiều năm kinh nghiệm nghiên cứu về các văn bản, cơ chế, chính sách cho hoạt động CNTT Cấp Phường/Xã nên trong phạm vi luận văn chưa thể nêu chi tiết, đầy đủ, còn nhiều thiếu sót.

- Việc xây dựng Chính phủ điện tử cấp Phường/Xã còn nhiều bất cập, khó khăn ở

Một phần của tài liệu (LUẬN văn THẠC sĩ) ứng dụng kiến trúc chính phủ điện tử và mô hình SAAS (software as a service) cho các dịch vụ phần mềm cấp phường,xã (Trang 53)