Jira Service Management Data Center용 자산 시작하기

개체

개체는 실제 자산/구성 항목입니다. 이는 Jira 이슈에 연결될 수 있으므로 문제가 발생하는 즉시 이슈는 더 많은 컨텍스트를 갖게 됩니다.

또한 개체가 서로 어떻게 의존하는지 보여주기 위해 개체 레퍼런스를 사용하여 서로 링크할 수 있습니다.

개체 스키마

개체 스키마는 개체 유형(아래 참고)과 개체를 포함하는 실제 구성 관리 데이터베이스(CMDB)입니다. 여러 목적으로 유용한 다양한 개체 스키마를 자산에서 만들 수 있습니다.

• 데이터를 작은 뭉치로 나누는 것은 데이터를 감사하고 정확하게 유지하는 데 유용합니다.
• 민감한 데이터, 예를 들어 고용 정보 등이 포함된 경우, 제한된 액세스 권한을 가진 하나의 개체 스키마에 모든 데이터를 함께 보관하는 것이 더 간편할 수 있습니다.

데이터를 자산에 넣는 방법을 결정할 때 데이터의 용도와 업데이트 주체를 고려하여 데이터를 논리적 개체 스키마로 그룹화해야 합니다.

어떤 개체 스키마가 어떤 정보를 포함하는지는 자산 (및 더 나아가 Jira Service Management)에 영향을 주지 않습니다. 하나의 커다란 데이터 풀일 뿐입니다. 즉, 하나의 사용 사례에 여러 개체 스키마를 쉽게 사용할 수 있으며, 서로 다른 개체 스키마의 개체 사이에 링크를 만들 수 있습니다.

개체 유형

개체 유형은 스키마 내에서 이동하여 스키마에 포함된 개체를 정의합니다. 개체를 직접 정의하거나 사용자 지정할 수 있는 특정 개체 유형으로 미리 채워지는 개체 스키마 템플릿을 사용할 수 있습니다. 개체 유형은 실제 개체의 컨테이너 역할을 합니다. 자산은 매우 개방적이고 유연하지만 일반적으로 다음과 같은 개체 유형이 있습니다.

• 비즈니스 서비스
• 호스트
• 노트북
• 소프트웨어

하지만 꼭 IT 자산일 필요는 없습니다. 예를 들어, 많은 사람들이 다음과 같은 유용한 정보를 추가합니다.

• 판매자
• 위치
• 직원
• 비즈니스 우선 순위

개체 유형 특성

개체 특성은 개체 유형을 정의합니다. 각 개체 유형에는 고유한 특성 집합이 있습니다. 예를 들어 '노트북' 개체 유형은 모델, 일련 번호, 사용자, 보증 만료 날짜 등의 특성을 포함할 수 있습니다.

특성에 대한 실제 값을 입력하면 개체가 정의됩니다. 이 작업은 수동 또는 자동으로 수행할 수 있습니다(4단계 참조).

개체 레퍼런스

구체적으로 호출할 개체 특성은 "개체"의 특성 유형입니다. 다른 개체에 대한 레퍼런스를 만들고 개체 간의 종속성 맵 빌딩을 시작하는 방법입니다.

예를 들어, 위치가 자체 개체 유형인 경우 각 위치 개체는 귀하의 지사들 중 하나일 수 있습니다. 예를 들어, '스톡홀름'을 선택하여 모든 노트북의 위치를 신속하게 설정할 수 있습니다.

자산 권한

자산에는 세 가지 유형의 권한이 있습니다

• 전역 권한 - 전역 설정에서 자산 관리 권한을 가질 사용자를 지정할 수 있습니다. “자산 관리자” 역할이 할당된 사용자는 자산 내에서 모든 작업을 수행할 수 있습니다.
• 개체 스키마 사용 권한 - 개체 스키마 설정에서 특정 개체 스키마에 대한 관리 권한이 있는 사용자, 개체 스키마 데이터를 업데이트할 수 있는 사용자 또는 데이터를 볼 수만 있는 사용자를 정의할 수 있습니다.
• 개체 유형 권한 - 때로는 Jira Service Management 고객에게 전체 개체 스키마의 모든 데이터를 볼 수 있는 액세스 권한을 부여하지 않고 특정 정보만 볼 수 있도록 하는 경우도 있습니다. 개체 유형 권한은 여기서 사용할 수 있습니다.

문제 정의하기

대부분의 도구는 문제를 해결하기 위해 구현하며 자산 역시 그렇습니다. 인시던트 해결 시간이 충분히 빠르지 않거나 특정 서비스를 변경하면 서비스 종속성을 쉽게 확인할 수 없기 때문에 예기치 않은 결과가 발생할 수 있습니다.

문제를 찾아 이를 통해 해당 사용자로부터 데이터베이스에 포함시킬 자산과 정보에 이르기까지 그 밖의 모든 것을 정의할 수 있습니다. 문제를 살펴보고 문제를 극복하기 위해 어떤 추가 정보가 필요한지 생각해 보세요. 이 정보가 개체 유형을 정의합니다.

한 번에 너무 많은 정보를 추가하면 정확성을 확인하기 어려울 수 있으므로 한 번에 한 가지 문제에 집중하세요. 첫 번째 문제를 해결했으면 자산이 확장하여 다른 문제를 해결할 수 있습니다.

서비스로 시작하기

구성 관리를 사용하는 경우 해결하려는 문제와 관련된 서비스부터 시작할 것을 권장합니다. 서비스는 잘 정의되어 있어 실행에 의존하는 다양한 자산, 그리고 해당 자산이 의존하는 자산 등을 추가하는 것이 비교적 간단합니다. 결국 각 관련 서비스 및 해당 종속성에 대한 완전한 그림을 빌드하게 됩니다.

어느 수준까지 데이터를 포함할지 결정해야 합니다. 현실적으로 서비스를 이해하는 데 필요한 세부 사항을 고려하십시오. 특정 랙과 케이블을 매핑하는 것은 어떤 랙과 케이블에 대해서는 지나치게 많은 것일 수도 있으며, 또 다른 경우에는 필요할 수도 있습니다.

또한 모든 서비스를 한 번에 수행할 필요가 없습니다. 비즈니스 크리티컬 서비스나 가동 중지 시간이 가장 긴 서비스부터 시작할 수 있습니다.

서비스 시작 시 함께 시작할 자산/구성 항목의 정의된 집합이 제공됩니다. 이후 새로운 문제가 발생할 경우 필요에 따라 다른 자산을 추가할 수 있습니다. 전체 인프라와 자산보다 작은 데이터 뭉치의 정확성을 한꺼번에 확인하는 것이 더 쉽기 때문에 CMDB를 비트 단위로 빌드하는 것이 가장 좋습니다.

개체 스키마 템플릿 사용

자산은 IT 자산 및 구성 관리, 인적 자원 및 고객 관계 관리를 위한 개체 스키마 템플릿을 포함합니다.

필요에 따라 수정할 수도 있지만 이 템플릿은 사용자가 자산에서 자주 저장하는 개체 유형으로 좋은 시작점이 될 수 있습니다. 개체 유형 목록에서 아래로 이동하며 사용하지 않을 개체 유형을 제거합니다.

귀하가 없어도 살 수 있는 것이 무엇인지 생각해 보세요.

달성하려는 내용과 거기에 필요한 정보에 대해 신중하게 생각합니다. 각 개체와 해당 특성은 유용해야 합니다.

귀하는 귀하의 팀 및 이해 관계자와 앉아서 각 특성이 누군가 또는 무언가에 의해 소비되고 있는지 확인할 필요가 있습니다. 아무도 특정 용도로 필요로 하지 않는 특성은 휴지통에 버려집니다. 또 언제든지 다시 추가할 수 있습니다!

서버의 정확한 위치를 알고 싶으신가요? 아니면 운영 체제 제조업체를 알고 싶습니까? 그러한 정보를 필요로 하는 것은 지극히 자연스러운 일이죠. 그러나 해당 데이터를 기반으로 결정을 내리거나 문의를 하지 않는다면 데이터는 스크랩 뭉치에 들어가게 됩니다!

너무 많은 데이터를 추가할 경우 처리가 어려울 수 있습니다.

• 개체와 특성이 많을수록 정확하게 유지하기 위해 더 많은 작업을 필요로 합니다.
• 미사용 데이터가 많으면 귀중한 데이터가 흐려지고 극단적인 경우 성능이 저하될 수 있습니다.
• 나중에 추가하는 것이 데이터를 제거하는 것보다 쉽습니다. 따라서 무언가를 놓치고 있음을 발견하면 만약을 대비하여 많은 데이터로 시작하기 보다는 나중에 추가하는 쪽을 택하십시오. 아무도 데이터 삭제를 좋아하지 않습니다.

향후 유지 보수 가능성 고려

자산에서 데이터를 유지 관리하는 방법을 고려하세요. 개체의 특성은 얼마나 자주 변경되며 자산에서 개체를 최신 상태로 유지하는 것은 어느 정도 용이합니까?

개체의 특정 세부 사항이 자주 변경되지만 거의 사용되지 않는다면 자산 밖에서 유지하면서 실제로 필요한 경우에 찾아보는 것이 더 합리적일 수 있습니다. 지금 사용되긴 하지만 빈도가 높지 않은 경우라면 접근 용이성 등의 측면에서 가치가 있을 수 있습니다.

노트북 소프트웨어를 예로 들어보겠습니다. 필요한 경우 검사 에이전트, 소프트웨어 요청 이슈 및 자동화 규칙을 사용하여 노트북에 설치된 모든 소프트웨어를 포함하도록 자산을 업데이트할 수 있습니다. 개방적 설치 정책이 있는 경우 상대적으로 빠르게 변경되며 검사 패턴이 새로운 소프트웨어를 감지하지 못하여 정확도가 다소 떨어질 수 있습니다. 대신에 특히 사용량을 이해하는 데 관심이 있는 주요 소프트웨어 집합을 살펴보는 것이 좋습니다.

엄격한 설치 정책이 있고 소프트웨어가 노트북 설정에 서비스 데스크 요청을 통해서만 설치가 가능한 경우, 변경 속도가 느리고 추적하기가 쉽기 때문에 자산에 모든 것을 저장하는 것이 좋습니다.

물리적 항목 이상을 생각하기

자산을 사용하면 필요한 개체를 정의할 수 있어 기존 자산이나 물리적 자산에 국한되지 않습니다. 예를 들어, 비즈니스 서비스는 물리적 자산이 아니지만 사용자가 자세히 이해하는 데 중요한 경우가 많습니다. 서비스의 모든 물리적 및 추상적 종속성을 해당 서비스에 연결할 수 있으므로 비즈니스 서비스 개체를 살펴보면 서비스가 어떻게 실행되는지 완전히 이해할 수 있습니다.

얼마든지 추상적으로 사용해도 됩니다. 사용자가 만드는 자산의 일반적인 예로는 비즈니스적 중요성 개체, 환경 유형, 부서/팀, 위치 등이 포함될 수 있습니다.

그 밖의 실제 사례로는 비즈니스 서비스 분류가 있습니다. 모든 비즈니스 서비스가 자산에 "비즈니스 서비스" 개체 유형으로 추가되었다고 가정해보겠습니다. 비즈니스 서비스를 "재무", "물류", "영업", "인프라" 등으로 분류할 수 있습니다. 비즈니스 서비스 개체 유형의 특성을 사용하여 이 작업을 수행하거나 이러한 범주를 '서비스 범주'라는 고유한 개체 유형으로 만들 수 있습니다.

앞을 보고 끊임없이 성장하십시오.

앞으로 사용해 볼만한 확장 기능을 염두에 둡니다. 이를 통해 귀하가 포함하려는 데이터뿐 아니라 데이터를 구조화하는 방법까지도 형성하게 됩니다.

이것을 염두에 두고 점진적으로는 자산을 구축하는 것이 좋습니다. 1,000개의 개체에 대해 100% 정확한 데이터로 대형 릴리스를 시도하는 것은 매우 어렵습니다. 작은 규모로 시작하여 새 특성, 개체 및 개체 스키마를 추가하는 것이 훨씬 간단할 수 있습니다.

문제를 찾고 자산을 빌드하여 문제를 해결한 다음 문제로 넘어가는 것이 좋습니다.

정확성에 대한 현실적 기대치 설정

항상 100% 정확도를 목표로 해야 하지만 실제로는 가능하지 않을 수 있습니다. 데이터가 처음부터 없는 것보다 더 많은 비즈니스 가치를 제공할 수 있을 만큼 충분히 정확하다면 긍정적입니다. 여러 CMDB 프로젝트가 진행되기도 전에 '완벽'을 추구함으로써 지연되거나 심지어 실패할 수 있습니다.

Asset Discovery 네트워크 스캐너

Asset Discovery는 Marketplace에서 무료로 사용할 수 있습니다.

Asset Discovery는 에이전트가 없는 스캐너(다만 에이전트를 통해 자세한 정보를 얻을 수 있음)로 네트워크 자산을 수집합니다. 자산 개체 스키마로 끌어올 자산과 특성을 선택할 수 있을 뿐 아니라 고유한 검사 패턴을 만들어 더 많은 틈새 자산을 찾을 수 있습니다. 일정에 따라 실행하는 경우 변경 사항을 선택하고 데이터를 업데이트한 상태로 유지하면 됩니다. 자동화 규칙을 사용하여 감지된 변경 사항에 따라 Jira 이슈, 이메일 알림 등을 트리거할 수도 있습니다.

가져오기 도구

다른 소스로부터 데이터를 가져올 때 자산 가져오기를 사용할 수 있습니다. 이러한 가져오기 규칙은 일정에 따라 동기화가 가능하므로 필요한 경우 데이터를 업데이트할 수 있습니다. 각 가져오기 유형에 대해 데이터가 저장되는 위치와 자산에서 이동해야 하는 위치를 정의합니다.

CSV 가져오기

모든 자산이 포함된 Excel, Sheets와 같은 스프레드시트를 사용하는 경우 CSV 가져오기 기능을 사용하여 데이터를 자산으로 가져올 수 있습니다. 이를 통해 자산을 이슈에 링크하여 영향을 분석하는 통합적이고 투명한 시스템을 확보할 수 있습니다.

데이터베이스 가져오기

데이터베이스 가져오기 기능을 사용하여 내부 또는 타사 시스템에서 데이터를 가져올 수 있습니다. 지원되는 데이터베이스에는 오라클, MySQL, 마이크로 소프트 SQL 서버, PostgreSQL 등이 있습니다.

Jira 사용자 가져오기

자산 사용자는 종종 Jira 사용자를 자신이 소유한 자산에 연결합니다. 이를 위해서는 Jira 사용자 가져오기를 통해 자산에서 Jira 사용자 또는 특정 사용자 그룹을 가져와야 합니다.

LDAP 가져오기

승인 프로세스에 사용되는 자산이나 직원-관리자 관계가 포함된 기업 디렉터리로 작업하고 있습니까? 자산에는 작업을 용이하게 하기 위해 디렉터리에서 구조와 자산을 가져와 널리 사용되는 LDAP 디렉터리와 함께 작동하는 모듈이 있습니다.

JSON 가져오기

데이터가 들어있는 JSON 파일을 사용하여 개체를 자산으로 가져올 수 있습니다.

통합

통합 기능을 이용하여 클라우드 서비스, 자산 관리자, 기타 CMDB와 같은 도구에 연결할 수 있습니다.

도구를 모두 갖추고 있더라도 도구의 가치를 낮출 계획이 없다면 모든 데이터를 자산으로 가져오지 않는 것이 좋습니다. Jira Service Management에서 사용해야 하는 것만 가져오세요. 나중에 언제든지 더 가져올 수 있습니다.

모든 통합은 Marketplace를 통해 무료로 설치할 수 있습니다.

자산 통합의 전체 목록은 다음과 같습니다.

• 자산 - AWS 통합
• 자산 - Azure 통합
• 자산 - Google Cloud 통합
• 자산 - SCCM 통합
• 자산 - Snow 통합
• 자산 - ServiceNow 통합
• 자산 - JAMF 통합
• 자산 - Device42 통합
• 자산 - 국가 취약성 데이터베이스 통합
• 자산 - Jira와 Bitbucket의 통합
• 자산 - Tempo 통합

유용한 정보와 팁

Asset Discovery, 가져오기 도구 및 통합의 실행 빈도에 대한 균형을 확보해야 합니다. 지나치게 빈도가 낮으면 자산이 최신 버전으로 유지되지 않습니다. 지나치게 빈도가 높으면 처리하는 개체의 수에 따라 많은 리소스를 소비할 수 있습니다. 통합을 매시간 실행하는 사용자도 있고, 일주일에 한 번 또는 필요할 때에만 실행하는 사용자도 있습니다.

바쁘지 않을 때 가능한 한 자주 동기화 하는 것이 좋습니다. 예상되는 데이터 변경 빈도와 데이터의 중요성을 확인하여 데이터 실행에 대한 예약 빈도를 결정합니다. 데이터가 얼마나 빨리 변하는지 사전에 알고 싶을 것입니다.

Asset Discovery를 사용하면 자산을 최대한 최신 상태로 유지하는 데 필요한 리소스를 절약하기 위해 서로 다른 검색 패턴을 다양한 빈도로 실행할 수 있습니다.

데이터를 논리적 개체 스키마로 분할하기

모든 데이터가 하나의 거대한 개체 스키마에 들어갈 필요는 없습니다. 데이터 사용 또는 데이터 소유자에 따라 여러 개체 스키마를 사용하는 것이 좋습니다.

자산과 Jira는 어떤 개체 스키마에 어떤 데이터가 포함되어 있는지 상관하지 않습니다. 어떤 스키마에 있든 관리자는 자산 사용자 지정 필드를 필요한 데이터로 연결합니다. 또한 사용자 지정 필드는 하나의 Jira 이슈에서 여러 개체 스키마로 데이터를 풀 및 푸시할 수 있습니다. 한 개체 스키마의 개체 간 링크는 다른 개체 스키마를 통해 만들 수 있으며 쿼리를 다른 스키마에서 실행할 수도 있습니다. 개체 스키마의 주된 목적은 자산 자체보다는 우리의 삶을 쉽게 만드는 것입니다.

데이터를 다양한 개체 스키마로 나누는 것은 사용자 친화적이며 유지 관리가 쉽습니다. 재무, HR 부서와 같은 팀은 자산의 일부 정보가 필요할 수 있지만 불필요한 정보까지 함께 받을 필요는 없습니다. 하나의 대형 개체 스키마의 특정 부분만 확인하도록 요청하는 것보다 한 팀에게 하나의 개체 스키마에서 데이터 품질을 정기적으로 확인하도록 요청하는 것이 보다 용이합니다.

데이터 통합

완벽하게 사용할 수 있는 데이터베이스 또는 정보 소스가 어딘가에 있고 업데이트 상태를 유지하는 프로세스가 이미 있는 경우 데이터를 자산으로 옮길 필요가 없습니다. 대신 통합을 사용하여 관련 데이터의 복사본을 만들고 자산 정보를 업데이트하기 위해 일정에 따라 해당 통합을 실행하는 편이 좋습니다.

자산은 다양한 가져오기 및 통합 기능과 함께 제공됩니다(위 참조). 이러한 가져오기 및 통합 기능을 통해 결정을 내리는 데 필요한 정보를 Jira 이슈/자산 자체에서 사용할 수 있지만 두 개의 복사본을 별도로 관리하지는 않습니다.

LDAP 가져오기를 통해 자산을 Active Directory와 동기화하는 경우를 흔히 볼 수 있습니다. 이제 모든 Windows 사용자에 대해 접근할 수 있고 동기화를 주기적으로 실행하여 업데이트된 상태를 유지할 수 있습니다.

가져온 데이터에 대해 별도의 개체 스키마를 만들거나 때로는 보다 큰 개체 스키마에 통합합니다. 데이터 다른 용도(예: IT 지원, HR 등)로 사용하는 경우, IT 개체 스키마와 직접 연결한 다음 해당 스키마에 대한 HR 액세스 권한을 부여하지 않고 별도의 개체 스키마로 사용하는 것이 좋습니다.

통합을 통해 사용 가능한 모든 데이터를 자산으로 가져오지 않는 것이 좋습니다. 통합을 설정할 때 개체 스키마에 포함할 항목과 포함하지 않을 항목을 결정할 수 있습니다. 또한 변경 사항을 원래 데이터 소스로 푸시하지 않는 한 자산 자체에서 이 데이터를 업데이트해서는 안 됩니다. 그렇지 않으면 데이터의 충돌이 일어나게 됩니다.

사용 가능한 사전 구축된 통합이 없는 경우 다른 옵션이 있습니다. 한 가지는 데이터를 CSV/JSON 파일로 주기적으로 내보낸 뒤 자산 CSV/JSON 가져오기 기능을 통해 일정에 따라 데이터를 가져오도록 하는 것입니다. 또는 개체를 만들고 거기에 추가 정보를 찾을 수 있도록 다른 데이터베이스에 연결되는 URL 특성을 부여할 수도 있습니다. 이 옵션은 에이전트가 정보를 볼 수 있지만 이를 기반으로 검색 또는 보고하는 것을 원하지 않는 경우에 적합합니다.

동일한 특성을 모든 곳에서 재사용하지 마십시오.

특성이 여러 곳에서 사용되고 동일 반복값을 가진다면, 자체 개체 유형으로 만드는 것이 더 좋은 경우가 많습니다. 이에 대한 좋은 예로 공급자가 있습니다. 예를 들어, 노트북 및 전화라는 개체 유형에 대해 '공급자' 라는 특성을 지정한 후 각 개체의 공자 이름을 입력하거나 가져올 수 있습니다.

이 것도 괜찮은 방법이지만 여러모로 '판매자' 개체 유형을 가지고 각 판매자를 개체로 설정하는 것이 보다 효율적입니다.

1. 공급자 이름 외의 정보를 원할 수 있습니다. 지원 연락처 또는 계약 링크와 같이 공급자와 관련된 다른 정보를 원할 수 있습니다. 모든 노트북과 휴대폰에 해당 작업을 반복하고 싶지 않을 수 있습니다. 이 경우 한 번만 실행한 후 공급자 개체에 링크하세요. Jira Service Management 내에서 공급자 관리 요소를 수행하려는 경우에도 도움이 됩니다.
2. 이 방법으로 공급자를 표준화하여 보고서를 더 쉽게 실행할 수 있습니다. 공급자별 지원 요청 수를 보고하려는 경우, 어딘가에 Micrsoft 또는 Apple이라고 쓰여 있기 때문에 누락되지 않은 것을 확신할 수 있습니다.
3. 판매자가 어떤 식으로든 다시 브랜딩하거나 변경해야 하는 경우 한 곳에서 업데이트하면 됩니다.

판매자뿐 아니라 비즈니스 중요도 수준, 배포 환경, 부서 및 위치 등을 포함합니다.

자산 자동화

자산 자동화는 각 개체 스키마에만 적용됩니다. 일반적인 사용 사례는 다음과 같습니다.

• 스키마의 자산 개체를 사용하여 특정 트리거 또는 변경 사항을 기반으로 알림 보내기(예: 라이선스 또는 보증이 만료되어 이메일을 보내거나 서비스가 중단되어 Jira 이슈를 만들 때)
• 간편한 보고 및 쿼리를 위해 자산 데이터를 깔끔하고 표준화된 상태로 유지.

자동화 규칙으로 개체 정보 업데이트, 이슈 만들기, 이메일 보내기, HTTP 요청, Groovy 스크립트 실행 등의 작업을 수행할 수 있습니다.

다음에서 자동화 규칙을 만드는 방법을 확인할 수 있습니다.

후속 조치

자산은 또한 새로운 전환 후 작동 기능을 제시합니다. 자동화 규칙과 마찬가지로 전환 후 작동을 사용하여 작업 실행을 자동화할 수 있습니다.

차이점은 Jira 워크플로(이슈 전환)를 통해 이슈의 상태를 변경할 때 작업이 수행된다는 것입니다. 이러한 작업은 자산 업데이트, 알림 전송 및 스크립트 실행이 포함합니다.

예를 들어, 직원의 온보딩을 요청하는 이슈가 만들어지면 필요한 자산을 자산 개체와 연결된 노트북, 휴대폰 및 휴대폰 가입 등을 포함하여 새로운 사용자에게 할당하는 작업을 만들 수 있습니다.

유용한 정보와 팁

이슈 텍스트 필드를 사용하여 자산에서 데이터를 입력하거나 업데이트하는 경우, 또는 자산에 수동으로 개체를 입력하는 경우에는 데이터가 다소 지저분해질 수 있습니다. 이러한 경우에는 자동화 기능을 사용하세요.

서버 이름이 좋은 예가 될 수 있습니다. 이러한 사항은 일반적으로 표준화되어 잘못 입력할 수 있습니다. 유형 서버의 개체를 작성하거나 업데이트할 때 트리거되는 자동화 규칙을 작성하여 이름이 명명 규칙과 일치하는지 확인하고 오류가 발생한 경우 플래그를 지정할 수 있습니다.

라벨 & QR 코드

레이블과 QR 코드를 사용하여 유형 자산의 관리를 간소화할 수 있습니다. 이를 위해 자산을 사용하면 모든 개체에 대한 레이블과 QR 코드를 인쇄할 수 있습니다.